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6.111- 1 General Technical Requirements 

The General Technical Requirements shall be applicable to all RFCS equipment, 

unless more specific subsystem specifications are provided in the subsequent 

Sections. 

6.111- 1.1 Physical and Materials Requirements 

(a) All equipment shall be designed for use in the transit industry, with specific 
attention to ergonomics, reliability, efficiency, and safety for passengers, 
operators, maintenance personnel and other system users. 

(b) Equipment furnished under these specifications shall be the latest model in 
current production, as offered to commercial trade, and shall conform to 
quality workmanship standards and use materials consistent with transit 
industry requirements. 

(c) The Contractor shall represent that all equipment offered under these 
specifications is new. 

(d) Used, shopworn, demonstrator, prototype, re-manufactured, reconditioned, or 
discontinued models are not acceptable. 

(e) All external screws, nuts, and locking washers shall be stainless steel or an 
approved alternate non-corrosive material; no self-tapping screws shall be 
used unless specifically approved. 

(f) All parts shall be made of corrosive resistant material, such as plastic, 
stainless steel, anodized aluminum or brass. 

(g) Equipment shall be designed to prevent unauthorized access, and to facilitate 
authorized access. 

1.1.1 ADA Requirements 

All equipment and devices shall comply with the requirements of 49 CFR 
Parts 27, 37, and 30 as amended through the date of this Contract, 
implementing the provisions of the Americans with Disabilities Act 
(ADA) of 1990, as amended. 

1.1.2 Modular Design 

(a) The Contractor shall utilize modular design throughout. 

(b) Standard, commercially available components shall be used 
wherever possible. 
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(c) All functionally identical modules, assemblies and components 
shall be fully interchangeable between all equipment acquired 
under this contract. 

(d) All modules and assemblies shall be connected using standardized 
durable, positive-locking, indexed quick disconnect fasteners. 

1.1.3 Upgradeability 

All equipment shall be modularly upgradeable so that it does not need to 
be replaced in its entirety to increase memory capacity, to upgrade 
processing performance, to reconfigure I/O options, or to maintain 
compatibility with ISO 14443 standards as they are developed and 
adopted. 

1.1.4 Vandalism 

Contractor shall include provisions to protect all equipment and 
components from common vandalism and physical abuse by individuals 
wielding portions of their body, or wooden or metallic implements. 

6.111-1.2 Software Requirements 

1.2.1 General Software Requirements 

(a) All software shall be written in a common and well-known modem 
high-level, highly structured language. 

(b) All software shall be the current version in production at the time 
of Phase II installation. Software versions to be approved by the 
Contract Administrator. 

(c) All software shall contain version control numbers. 

(d) Features shall be provided to identify the software version on each 
device, and verify that it is the correct or most recent version for 
that device. 

(e) All use of assembly/machine language shall be submitted for 
review and approval during the design review. 

(f) Software shall be organized in a modular, table-driven fashion to 
the extent possible. 

(g) Adjustable, Agency specific and customization parameters shall 
not be hard-coded onto the source-code; they shall be user- 
modifiable. 
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(h) Application software (both user and system) shall be portable, i.e. 
the source code shall be transferable to other computers using the 
same operating system without any modifications. 

(i) The application software shall be scaleable to newer, higher 
performance hardware or operating systems. 

(j) The application software design shall be developed using 
structured software development methods (to be approved by the 
Contract Administrator), and shall be submitted for the design 
review. 

(k) The system shall contain all supporting software required to 
implement, operate, modify, and maintain all graphics displays and 
interactive screens. 

(l) Passwords shall not be displayed on Video Display Units. 

(m) All software shall be self-diagnostic. 

(n) All source code shall include application and individual module 
descriptions. 

(o) All user and system interfaces shall have online help features. 

(p) The operating system should be standardized for all systems and 
Year 2000 operability must be provided. 

1.2.2 National Architecture Conformance 

(a) The RFCS shall demonstrate conformance with the Intelligent 
Transportation Systems (ITS) National Architecture as defined in 
6.III-1.2.2(b). Information on the National Architecture can be 
found at http://www. its. dot. gov/aconform/aconform. htm 

(b) The Contractor shall prepare and submit for review and approval a 
National Architecture Conformance Plan (CDRL 30), including at 
a minimum the following: 

i. Elements of the RFCS affected 

ii. Applicable standards 

iii. Description of approach to achieving ITS conformance 

iv. Description of conformity to the Central Puget Sound ITS 
Regional Architecture. Reference documents are available 
at: 

http://www.psrc.org/datapubs/pubs/reg arch.htm 
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and 

http://www.psrc.org/proiects/its/documents/guidance.pdf 
The RFCS project is included in the Regional Architecture. 

v. Approach to achieving the requirements of “Federal Transit 
Administration National ITS Architecture Policy on Transit 
Projects, Section VI, Project Implementation”. This 
document is available online at 
http://www.its.dot.gov/aconform/Policy 2.htm 

vi. Approach to incorporating the emerging Transit 
Communication Interface Profiles (TCIP). It is the 
Agencies desire to develop component and subsystem 
interfaces that are open, defined, and compliant with the 
emerging TCIP standards. At a minimum, fare transaction 
data elements downloaded to the DACS shall utilize TCIP 
where possible, and the FTP shall be able to accept location 
data in TCIP format. Information on TCIP can be found at 
http://www.ite.org/standards/tcip.asp 

(c) As part of the National Architecture Conformance Plan, the 

Contractor shall identify the applicability of, and compatibility 
with, the emerging Dedicated Short Range Communications 
(DSRC) standard. For current information regarding this standard 
contact: 

Mr. William Jones 

Technical Director 

US DOT, ITS Joint Program Office 

400 Seventh Street SW 

Room 3416, Mailstop HOFT-l 

Washington, DC 20590 

Tel: 202-366-2128 

email: william.s.jones@fhwa.dot.gov 

6.111-1.3 System Security 

The Contractor shall develop a comprehensive System Security Plan (CDRL 31) 
which identifies the system elements which require protection, and identifies 
mechanisms, procedures and processes to counter security threats to those elements. 

(a) The System Security Plan shall describe the intended functionality 
for each of the system security elements, shall identify security 
threats, and shall describe procedures, functions and systems for 
detecting and mitigating those threats. 
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(b) The System Security Plan shall identify system users, and describe 
rules that govern how those users will have access to system data, 
resources and processes. 

(c) The System Security Plan shall identify methods of detecting 
security breaches regardless of whether there is a detectable change 
in the performance of the system. All security breach detection’s 
shall be confidential, and accessible only to users with appropriate 
access permission. 

(d) Security provisions for owned and non-owned communications 
networks shall be described. 

(e) The System Security Plan shall be submitted with the design 
documentation. 

(f) The System Security Plan shall be approved by the Contract 
Administrator. 

(g) The Contractor shall implement system security services to achieve 
the approved System Security Plan. 

(h) The Contractor shall be responsible for providing security for 
RFCS equipment regardless of existing security facilities and 
systems provided by the Agencies or others. 

1.3.1 System Elements and Protection 

(a) At a minimum, the system security shall protect the following 
types of RFC system elements: 

i. Equipment and facilities installed in public locations. 

ii. Equipment and facilities installed in Contractor-owned or 
operated locations. 

iii. Equipment and facilities installed in Agency-owned 
facilities. 

iv. Software source and compiled code. 

v. Data communications and interfaces. 

vi. Other communications and interfaces as might be required 
for the work. 

vii. System data. 

(b) The Contractor shall coordinate with each Agency to develop 
system security elements and procedures that function with 
existing Agency firewalls. 
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1.3.2 System Security General Services 

At a minimum, the system security shall provide the following types of 
services: 

(a) All RFC systems, subsystems and devices shall allow only 
authorized users access. 

(b) The system shall provide access control based on the establishment 
of groups, users and roles: 

i. Groups, users and roles shall be assigned during system 
implementation as directed by the Contract Administrator. 

ii. A minimum of ten (10) groups shall be provided for. 

iii. Each user shall have a unique identification and password. 

iv. The system shall include flexibility to add new groups, 
roles and users, redefine groups and roles, and reassign 
access permission as part of normal system operations. 
Access permission shall be assigned by the System 
Administrator. 

(c) All system access shall be recorded. 

(d) The system security shall include features to limit the propagation 
of access permission. 

(e) For all data transactions, the system security shall include 
authentication features to verify that all claimed source, recipient 
or user identities are correct and valid. 

(f) All data transactions shall include non-repudiation features to 
verify message content, and resolve claims that data was not 
correctly originated or received by a certain user. 

1.3.2.1 Protection from Unauthorized Access 

As a minimum, the system security shall provide protection from 
intentional or accidental unauthorized access including the following: 

(a) Physical access to equipment or facilities. 

(b) Access to Contractor provided computing systems and software. 

(c) Access to Agency computing systems and software. 

(d) Access to funds, accounts and funds-related data, owned and non- 
owned. 
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(e) Destruction, removal, corruption or modification of data or other 
resources. 

(f) Interruption of service, including as a minimum component, 
device, subsystem or system operation, and system 
communications. 

(g) Access to any system stored or created data. 

1.3.2.2 Data Integrity 

The system security shall provide features to maintain data integrity, 
including as a minimum: 

(a) Error checking shall be provided. 

(b) Data transferred from a device or system shall not be purged or 
written over until a successful transfer is confirmed. 

(c) Features shall be provided to ensure that all transaction and 
system-created files are uniquely identified, and that no files are 
lost or missed during data transfer. Verification features shall be 
provided to confirm that there have been no losses of data at any 
point in the system. 

(d) Verification features shall be provided to confirm that there have 
been no unauthorized changes to or destruction of data. 

(e) Features shall be provided to automatically detect, correct and 
prevent the propagation of invalid or erroneous data throughout the 
system. 

1.3.2.3 Data Confidentiality 

(a) The following types of confidential data shall be maintained in the 
system: 

i. Transaction data related to an individual Agency, employer 
or other system user 

ii. Personal information on cardholders 

iii. Revenue and other system-confidential data. 

(b) The system security shall include the following minimum data 
confidentiality features: 

i. Features to prevent access to personal or other confidential 
data by unauthorized users 
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ii. Features to prevent unauthorized association of a user 
identity with user-specific activities 

iii. Recording and audit of actions taken by that user. 

1.3.3 Security Mechanisms 

The Contractor shall identify and document the specific mechanisms to be 
used to implement the system security services in accordance with the 
plan. At a minimum, the following information shall be provided. 

(a) For non-cryptographic mechanisms: 

i. Identification of the security devices for equipment and 
personnel. 

ii. Description of access control for applications. 

iii. Description of the secure routes for the transmission of data 
and resources. 

iv. Participants certification process. 

v. Trusted hardware and software components. 

vi. Security access process as granted by defined roles. 

(b) For cryptographic mechanisms: 

i. Description of encryption, including symmetric (private 
key) and/or asymmetric (public key), for confidentiality. 

ii. Description of the hash functions for message integrity 
checks. 

iii. Description of the digital signatures for authentication and 
non-repudiation. 

(c) For cryptographic support mechanisms of keys: 

i. Generation, distribution and archiving. 

ii. Directories and certification. 

iii. Recovery/escrow. 

1.3.4 Alarms 

(a) As a minimum, the system shall provide the following alarms, and 
shall notify the appropriate users in the event an alarm is triggered: 

i. Detection of invalid or erroneous data. 

ii. Detection of a security breach. 

iii. Detection of a device or system fault. 
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(b) All alarms shall be recorded and stored in a database, along with a 
history of corrective actions. 

(c) Users with associated privileges shall be able to manually override 
alarms. 

(d) Alarms that are manually overridden shall reactivate at a user- 
defined period until corrective action is taken and the alarm 
cleared. 

6.111-1.4 Data Backup and Recovery 

(a) The Contractor shall prepare a comprehensive data backup and recovery plan. 
(CDRL 5) 

(b) The Contractor shall provide a data backup system for data archiving and 
recovery. The data backup system shall include capabilities for an Agency to 
back up data through network-wide backup. 

(c) It shall be possible to recover and transfer data files in the event of a primary 
data storage failure through a secondary standardized PC interface such as an 
RS 232 port. 

(d) In the event of a primary data storage failure and/or backup data storage 
battery failure, an indication on the display shall alert the clearinghouse 
system. 

(e) Correct password entry shall automatically enable RFCS device to download 
the transaction data to the back-up device. 

i. Neither the RFCS equipment nor the backup device shall capture 
the correct password. 

ii. Unsuccessful attempts to enter the password shall be logged. 

iii. The log shall contain detailed information, including the date, time, 
location, RFCS equipment number, and erroneous password. 

(f) An alternate process for initiating data extraction and/or alternate means of 
removing data records may be provided which shall be subject to Contract 
Administrator review and approval. 

(g) The Contractor shall provide a detailed description of alternate process for 
initiating data extraction and/or alternate means of removing data records and 
the technical details necessary for Contract Administrator evaluation. 
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6.111-1.5 System Reliability and Availability Requirements 

1.5.1 Reliability Requirements 

Reliability is defined as Mean Transactions Between Failures (MTBF) that 
a specific type of RFCS equipment in service is performing. Transactions 
are defined as completed load or payment transactions. Figure IE-1.1 
provides a summary of the reliability requirements for relevant RFCS 
equipment. 

(a) In a low transaction volume environment, reliability (MTBF) 
shall be calculated as follows: 

i. Operating time for each type of equipment shall be summed 
and the result divided by the number of chargeable failures. 
FTPs shall be considered operational unless reported non- 
operational. 

ii. A low transaction volume environment is defined as any 
FTP processing zero (0) up to 250 transactions per day. 

(b) In a high transaction environment, reliability shall be calculated 
as follows: 

i. All transactions (full patron cycle) for each type of 
equipment shall be summed and the result divided by the 
number of chargeable failures. 

ii. A high transaction volume environment is defined as any 
FTP processing 251 and higher transactions per day. 


Figure MI-1.1 

EQUIPMENT RELIABILITY SECTION REFERENCES 


Equipment 

Section Reference 

Fare Card 

6.111-2.3.1 


6.MI-2.3.2 

Fare Transaction Processor (all configurations) 

6.111-3.3.2 

Driver Display Unit 

6.MI-6.3 

Wireless Data On-Off Load System 

6.111-7.3 

TVM Integration 

6.111-10.3 

Customer Service Terminal 

6.111-11.3 

Data Collection System 

6.111-12.3 

Back Office Client Computer 

6.111-13.5 


1.5.2 Availability 

The Contractor shall prepare a System Availability Measurement Plan 
(CDRL 39). Availability is defined as the probability that a device, a 
subsystem of a device, or a data server or computer system is operating. 
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The base equation presented in Figure III-1.2 shall be used to calculate 
availability. The four primary components of availability are: 

(a) Required operating hours = time the equipment is required to be 
available to conduct transactions or other operational activities. 

(b) Scheduled maintenance hours (as applicable) = time required for 
predefined scheduled equipment and system maintenance and 
servicing activities. 

(c) Required revenue servicing hours = time required for revenue 
servicing activities such as exchanging money containers, and 
replenishing card and receipt stock. 

(d) System out-of-service hours = time that the relevant system is not 
available to conduct transactions within the predefined scheduled 
operating window. 

Figure MI-1.2 

AVAILABILITY BASE EQUATION 

Availability = Effective operating hours - System out-of-service hours 

Effective operating hours 

where: effective operating hours = [required operating hours - (scheduled 
maintenance hours + required revenue servicing hours)]. 

1.5.3 Failure Review Team 

A Failure Review Team (FRT) shall be established to evaluate which 
failures are chargeable against the Contractor’s reliability requirements. 
The FRT shall be comprised of, as a minimum, one member from the 
Agencies or designated Agency representative, and as a minimum one 
member from the Contractor. Responsible parties within this team will 
initially attempt to settle any disputes. The Contract Administrator will 
give its opinion on any disputes that remain unsettled after a period of two 
weeks after the FRT meets to evaluate a specific failure. In the event the 
Contractor does not agree with the Contract Administrator, it may resolve 
the issue pursuant to the disputes procedure set out in Section 3.1-72, 
Conflict Resolution. 

1.5.4 Corrective Action 

(a) In the event that the devices do not meet the reliability 

requirements, the Contractor shall identify and implement remedial 
action, including, as necessary, modification of the equipment, on¬ 
site engineering services, on-site technical services, or other related 
action at no cost to the Agencies. 
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(b) In the event the installed equipment does not meet these 
requirements, and remedial action requires the Contractor to take 
an individual device (other than depot maintenance devices) out of 
service for more than 12 hours to implement equipment 
modifications or replacement, the Contractor shall arrange for a 
supplemental device at that location as necessary, so there is no 
reduction in service while remediation is taking place. 

(c) The Contractor shall provide a replacement device within 24 hours 
of notification. 

6.111-1.6 Electrical Requirements 

1.6.1 Equipment Power Supply 

All Equipment installed in Agency or third party facilities with the 
exception of any on-board equipment shall operate from a nominal line 
voltage of 120 VAC, within voltage tolerances of +10% to -10%, and a 
frequency range of 57 Hz to 63 Hz without equipment damage. 

1.6.2 Electrical Protection and Grounding 

(a) The Contractor shall provide equipment that meets applicable 
specifications and criteria of the Underwriters Laboratories 
Incorporated (UL), National Electrical Code (NEC), and the 
regulations of the State of Washington and local jurisdictions. 

(b) The Contractor shall be responsible for securing Underwriters 
Laboratories and other electrical certifications, and shall be 
responsible for any costs associated with the certification process 
and/or inspections. 

(c) All device enclosures shall contain an easily accessible master 
circuit breaker that will remove power from the equipment when 
tripped. Circuit breakers shall clearly indicate when they have 
been tripped. 

(d) All enclosures, chassis, assemblies, panels, switch boxes, terminal 
boxes, and similar enclosures or structures shall be grounded. 

(e) Protective grounding shall be provided to ensure that all exposed 
metal equipment and metal fixtures are connected to a common 
ground point in the electrical cabinet. 

1.6.3 Wiring 

(a) Conductors that have the potential of operating at 50 volts or more 
shall not be bundled with any other lower voltage conductors. 
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(b) Wire dress shall allow sufficient slack for three (3) additional “re¬ 
terminations” without excess tension. 

(c) Wire splices are not permitted. 

(d) Wire and cable ties shall not be so tight as to cause indentation and 
damage to the insulation. 

(e) Adhesive-mounted bases shall not be used to support wire ties or 
cable supports. 

(f) All conductors within each enclosure shall be installed free from 
metal edges, bolt heads, and other sharp or interfering points. 

(g) All conductors providing connections between components shall 
be provided with strain-relief, and be clear of moving objects that 
could damage either the conductor or the object. 

(h) All terminations and cables must be clearly indexed, labeled and 
schematically identifiable. All wire labels shall be non-metallic 
and shall resist standard lubricants and cleaning solvents. 

(i) When components must be connected to each other through 
individual wires, the wiring shall be incorporated into a wiring 
“harness,” where each branch of each circuit can be separated from 
others for troubleshooting. 

(j) All components interconnected through individual wires contained 
within a “harness” shall be disconnected from the harness by 
disconnecting a durable, positive-locking, indexed quick 
disconnect fastener. 

1.6.4 Printed Circuit (PC) Boards 

(a) Where possible, all components shall be connected to the main 
logic circuitry by plugging into slots on a printed circuit 
“backbone.” 

(b) All PC boards shall be interchangeable with the same printed 
circuit board on other devices purchased under this contract. 

(c) All PC boards that have through holes shall be through hole 
plated. 

(d) All PC boards shall be at least NEMA Grade FR-4, epoxy glass, 
green with weave appearance, and shall have a heat/mechanical 
load limit of 5. The 5 indicates the “peel strength” of the laminate 
(pounds per inch of width needed to peel off a strip of copper 
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cladding at an elevated temperature, NEMA publication LI 1- 
1971). The copper laminate shall be firmly affixed to the PC board 
and shall not blister or peel when heated with a soldering iron. 

(e) The component side of the board shall be silk-screen printed with 
component references and other identifying information which 
corresponds to PC board schematics to aid in repair and 
troubleshooting. 

(f) Sufficient clearance between components shall be provided to 
allow for component testing, removal, and replacement. 

(g) Identifiable test points for circuit troubleshooting shall be provided 
on modules and PC boards. 

(h) All markings on PC boards shall be in English. 

(i) All PC boards shall have a unique, permanent serial number that 
cannot be altered during normal repair. 

(j) Fuses or built-in protection shall be provided on all driver circuits 
to prevent damage to those transistors or other devices that drive 
relays, solenoids, print heads, and motors. The fuses shall be easily 
replaceable without damaging the PC board. 

(k) All PC boards shall be “indexed” to prevent insertion in the wrong 
slot or the wrong direction. 

(l) All PC boards shall contain the manufacturer catalog or reference 
number, version level and serial number for tracking purposes. All 
such identifiers shall be permanently affixed to the board. 

(m) PC boards in on-board equipment shall employ pin/socket 
connectors, and shall not use printed card edge fingers. 

1.6.5 Relays 

(a) The contact tips of any relays shall not be placed in parallel for the 
purpose of carrying a current load at or above the manufacturer's 
contact tip rating. 

(b) Bifurcated contacts shall be used in low-voltage applications 
whenever necessary due to dry contact switching requirements. 

(c) All relays shall be installed such that they are fully accessible for 
testing, removal and replacement. 
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(d) All relays shall be socketed with captive spring retainers to hold 
relays in place. 

1.6.6 Switches 

(a) Poles of switches shall not be placed in parallel to carry current at 
or in excess of manufacturer's contact pole rating. 

(b) Switches shall be provided with a “keying” feature such that, after 
installation, the body of the switch will be constrained from 
mechanical rotation. 

1.6.7 Equipment Enclosures 

Equipment will be installed in indoor and outdoor environments, with 
various levels of sheltering ranging from significant protection to none. 

All outdoor equipment shall be designed for exposure to salt laden marine 
air, fog, rain, hail, and other environmental conditions prevalent in the 
Puget Sound Area. 

(a) RFCS equipment shall be able to operate under additional 

environmental requirements presented in the respective subsystem 
technical specifications as applicable. 

(b) Enclosures shall include any provisions necessary to maintain the 
internal equipment at an acceptable temperature and humidity. 

(c) Enclosures shall be designed to prevent entry of moisture during a 
driving rainstorm and to minimize entry of dust. 

(d) Any moisture or dust entering the enclosure shall not cause short 
circuits or equipment failure. 

6.111-1.7 Environmental Requirements 

1.7.1 Electromagnetic Compatibility 

The Contractor's approach to electromagnetic compatibility shall ensure 
that the electrical and electronic components and subsystems operate in 
their intended operational environments without being affected by or 
causing harmful interference. Protection shall be provided against radio 
frequency and electromagnetic interference (RFI/EMI) emission sources, 
as well as internal conductive or inductive emissions. 

(a) Operation of RFCS equipment shall not be affected by the 

electromagnetic fields generated by utility transmission lines, by an 
overhead catenary at distances as close as 25 feet, or by local 
power distribution lines at distances as close as 50 feet. 
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(b) Operation of RFCS equipment shall not be affected by 
electromagnetic effects present during transit operations such as 
electric trolley buses and light rail vehicles. 

(c) Operation of RFCS equipment shall not affect or be affected by 
equipment in the Bus Tunnel, LRT right-of-way or at WSF 
terminals. 

(d) Operation of RFCS equipment shall not affect or be affected by 
other on-board equipment including vehicle power supplies, radios, 
automatic vehicle identification systems, and on-board data 
collection and processing equipment. 

(e) Contractor shall describe what provisions shall be included for 
EMI/RFI protection. 

(f) The Contractor shall certify through the Contractor’s expense the 
electromagnetic compatibility of equipment to be furnished. 

(CDRL 32) 

(g) Equipment shall meet applicable codes, standards and specifi¬ 
cations at the time of manufacture. 

(h) On-board equipment and card reading equipment connected to a 
customer service terminal, Sound Transit ticket vending machine 
or other revalue device shall meet the following standards. Subject 
to written approval from the Contract Administrator, the 
Contractor may apply for a waiver of certain tests for office-based 
computer equipment and card reading equipment installed at 
Sound Transit ticket vending machines. Onboard and rail platform 
equipment shall be subject to all identified tests. 


Specification 

Standards 

Electrostatic Discharge 

IEC(EN) 61000-4-2 

Radiated Electric Field 

IEC(EN) 61000-4-3 

Conducted Electric Field 

lEC(EN) 61000-4-6 

Conducted Transient Burst 

IEC(EN) 61000-4-4 

Conducted Surge 

IEC(EN) 61000-4-5 

Magnetic Fields 

IEC(EN) 61000-4-8 

Emissions 

CISPR 22 (EN 5022) 


6.111-1.8 System Documentation 

1.8.1 Documentation Control and Management 

(a) All software and versions used to produce documentation shall be 
provided to and approved by the Contract Administrator. 
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(b) All system documentation, including manuals and training 
materials, shall be available for download via a project website. 

(c) Unless otherwise specified at least seven paper and electronic 
copies of documentation shall be provided to the Contract 
Administrator. 

(d) All draft electronic documentation shall be provided in Adobe 
Acrobat PDF format suitable for printing. All final electronic 
documentation shall be provided in both Adobe Acrobat PDF 
format and native file format. 

(e) The Agencies shall have the right to reproduce and reuse all 
documentation, subject to Intellectual Property rights and 
requirements as defined in Division I. In all cases, the Agencies 
shall have the right to reproduce, reuse and distribute all 
documentation within an Agency for the purpose of operating and 
maintaining the RFCS. 

1.8.1.1 Documentation Website 

The Contractor shall establish and manage all system documentation via a 
project website 

(a) All documentation shall be downloadable in a usable format 
through this website. 

(b) Access to the website and access to documents within the website 
shall be user and password controlled and available only to users as 
necessary, as identified by the Contract Administrator. 

(c) The Contractor shall update the website with the latest versions of 
documents throughout the Contract. 

(d) Documentation shall be in the English language. 

(e) Website structure shall be indexed using system documentation 
type and/or a logical grouping. 

1.8.2 Manuals 

1.8.2.1 General Requirements 

The Contractor shall supply the full complement of manuals and 
documentation required to train Agency personnel to operate and maintain 
all system components installed in or on Agency facilities, or operated by 
the Agencies. Manuals shall be provided according to an agreed upon 
schedule (CDRL 33, Required Manuals Schedule). Manual shall be made 
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available in two forms, on the project website and hard copy final versions 
provided to the Contract Administrator. All manuals shall be: 

(a) In the English language. 

(b) Divided and tabbed into logical and/or functional sections. 

(c) Indexed. 

(d) Cover both the hardware and the software associated with each 

system. 

(e) Updated as required over the life of the Contract to reflect all 
configurations operational in the field. 

(f) Furnished as “Controlled” documents and each manual shall 

contain a unique number. 

i. All revisions shall be issued by manual number. 

ii. Revisions to draft and approved manuals shall be recorded 
on a control list to be maintained in the front of each 
manual. 

iii. The list shall be issued with each revision and shall contain 
the date of the revision and the page references for that 
revision. 

(g) The training documentation shall be separate from the operation 
and maintenance manuals, but may reference those manuals. 
(Training documentation requirements are defined in Section 
6.II-12, “Training Requirements.”) 

1.8.2.2 Paper Format 

(a) Manuals shall be designed to withstand continuous, long-term use 
in a commercial environment. 

(b) Manuals shall lie flat when opened and permit easy addition and 
replacement of pages. 

(c) Covers for all manuals shall be made from materials that are oil, 
water and wear resistant. 

(d) Pages shall be 8/2 x 11 inch except where otherwise specified and 
double sided. 

(e) Sides of pages intentionally left blank shall be so noted. 
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(f) Figures, illustrations, diagrams, and drawings shall be labeled as 

figures. Figures may be a maximum of 11x17 inch, folded to 8 V 2 x 
11 inch with the identification clearly marked. 

1.8.2.3 Computerized Format 

(a) The Contractor shall supply manuals, catalogs, diagrams, views, 
illustrated parts catalog, troubleshooting flow charts, and schematic 
drawings in electronic form on CD ROM in the following formats: 

i. Text shall be provided in the latest version (current 
production version at deployment, as agreed to by the 
Contract Administrator) of Adobe Acrobat, and Microsoft 
Word or approved commercially available word processing 
program for native format files. 

ii. Drawings shall be provided in .eps or .dxf file formats. 

iii. Graphics files shall be provided in TIFF, GIF and/or JPEG 
formats. 

(b) The Contractor shall be responsible for updating manuals to reflect 
current RFCS parameters in the event that changes are made to the 
system or operational procedures. Manuals shall be updated and 
maintained by the Contractor throughout the life of the Contract, 
and provided to the Agencies in a timely manner in the formats 
specified above. 

1.8.2.4 System Operations Manual 

Seven (7) copies of the System Operations Manual (CDRL 34) shall be 
provided. The Contractor shall include one (1) copy on an electronic file. 
The document shall include the following: 

(a) Complete diagrams. 

(b) Illustrations. 

(c) Instructions for operation of the system, including normal 
operating and communications procedures. 

(d) Diagnostic procedures. 

(e) Restart/recovery procedures. 

(f) Other necessary procedures for operating the system. 

(g) Complete descriptions of functions necessary for generating 
reports. 
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1.8.2.5 


1 . 8 . 2.6 


1.8.2.7 


System Maintenance Manual 

Seven (7) copies of the System Maintenance Manual (CDRL 35) shall be 
provided. This document shall be comprehensive and shall provide 
complete detailed technical descriptions of maintenance operations, 
including, but not limited to, the following: 

(a) General descriptions. 

(b) Theory of operations. 

(c) Preventive maintenance schedule and activities. 

(d) Troubleshooting techniques. 

(e) Corrective measures, both temporary and permanent. 

(f) Locations and availability of support services for all major 
components. 

(g) Point-to-point component wiring schematics. 

(h) Assembly and disassembly drawings. 

(i) Installation guidelines. 

(j) List of required maintenance tools. Complex tools and test 
equipment each require a separate operators manual (CDRL 36). 

(k) Component parts lists. 

(l) Schematic diagrams. 

Software Documentation 

Software Documentation (CDRL 37) shall be provided as described in the 
Contract. 

Current Parts List (CPL) 

The Contractor shall provide a comprehensive and detailed Current Parts 
List (CPL) for each and every component included in the system. Parts 
shall be numerically coded for inventory purposes. 

(a) The CPL (CDRL 38) shall be categorized and related to particular 
system components. 
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6 . 111 - 1 . 


(b) The CPL shall contain the source vendor’s name, identification 
numbers and codes, or other means to identify the manufacturer of 
each component. 

(c) The CPL shall include prices and quantity discounts offered. 

(d) The CPL shall identify new component and products that will be 
developed for this application, as well as note which products are 
replacing existing equipment. 


9 Audit 

The Contractor shall provide the audit capabilities to track all RFCS transactions from 
conception to settlement. 

(a) The system shall create and maintain an audit trail of accesses to the objects it 
protects. 

(b) The audit mechanism shall permit the specific auditing of the actions of one or 
more users based on the individual’s identity or security/administrative role. 

(c) Audit data shall be protected so that read access to the data is limited to those 
subjects authorized for review of audit data. 
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6.111- 2 Fare Card 

6.111- 2.1 Subsystem Description - Fare Card 

The RFCS fare card will be the regional fare media accepted at all participating transit 
Agencies for fare payment. It is the intent to introduce a contactless-only card to 
support the RFCS project, with the potential to accommodate a dual interface card in 
the future operating in parallel with the contactless-only card. All systems and 
equipment in the RFCS shall support the contactless interface. 

(a) The fare card (DR 101) shall be a memory or microprocessor smart card with 
a contactless interface. The contactless interface shall be used for all 
communications and transaction processing between the fare card and RFCS 
equipment. 

(b) The card shall be technically capable of both reading and updating uniquely 
stored RFCS information through the contactless interface. 

(c) Agency access to any non-RFCS applications that may be resident on the card 
shall be restricted without written authorization from the owner of the non- 
RFCS application. 

(d) The fare card shall be designed to support the addition of a magnetic stripe to 
ABA standards, and be imprinted with custom artwork and photographs on the 
front and back. 

(e) RFCS data shall not be accessible by any non-RFCS application without 
written authorization from the Contract Administrator. 

(f) The fare card shall include an electronic and printed serial number. In the 
event that the electronic serial number differs from the printed serial number: 

i. The Contractor shall provide an electronic file cross referencing 
electronic and printed serial numbers with every card order. 

ii. The RFCS shall provide access to all card information via either 
the electronic or printed serial numbers, and shall maintain a cross- 
reference of the two. 

6.111- 2.2 Functional Requirements - Fare Card 

2.2.1 Card Operating System 

The Contractor shall provide a Card Operating System (COS) that 

conforms to the following requirements (DR 101.01): 

(a) The COS shall support a multi-application structure to allow for 
the creation and addition of new applications without interfering 
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with the existing ones. (If multiple applications are used in 
conjunction with an open electronic purse, then any application 
added to the card shall be subject to the approval of the open 
electronic purse association to ensure the integrity of the open 
purse scheme.) 

(b) The COS shall allow the updating and/or the removal of existing 
applications. 

(c) The Contractor shall provide detailed information of how the COS 
will be designed to secure and safeguard the integrity of transaction 
data stored on the card such as the file protection function, data 
encryption algorithms, and/or Message Authentication Code 
(MAC). 

(d) The Contractor shall provide detailed information on how data 
integrity will be maintained and transactions completed for 
contactless operation. 

(e) The transaction speed requirements specified herein shall not be 
impacted by the COS security features design, specifically through 
the card’s contactless interface. The Contractor specifications 
(DR 101.02) in that regard are subject to Program Manager review 
and approval. 

(f) The COS shall support blocking of Agency issued cards and 
blocking of the RFCS application on a third party issued card. 

i. Requests for card unblocking shall be allowed by an 
authorized customer service representative only. 

ii. The COS shall support blocking only the RFCS application 
on a non-Agency issued card in a multi-application 
environment. 

iii. The blocking and unblocking function shall be controlled 
by the clearinghouse in accordance with RFCS policy. 

2.2.2 Disposable Card 

The Contractor shall provide disposable contactless-only cards (DR 

101.03) that shall have limited functionality for short term applications in 

targeted markets at a low cost. 

(a) The disposable card shall be configurable in any denomination of 
value or pass validity, or as a visitor, group or special fare 
instrument. 
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(b) The Agencies shall be able to order disposable smart cards pre¬ 
valued, or shall be able to value the cards at the time of issuance. 

2.2.3 Smart Objects (Option) 

The Contractor may provide Smart Objects (e.g. key chains) (DR 101.04) 

that have the contactless hardware embedded into the device. Smart 

Objects may have full RFCS functionality, or limited functionality. 

(a) Smart Objects shall serve specific applications in target markets. 

(b) Smart Objects shall have a unique serial number and may be 
reloadable. 

(c) The use of Smart Objects are subject to successful completion of 
all specified testing requirements. 

6.MI-2.3 Performance Requirements - Fare Card 

2.3.1 Card Reliability 

(a) Card failure is defined as, but not limited to, the inability to 
complete a transaction, the loss of value due to IC chip failure or 
electrical connection, or physical mechanical failure of card 
material, except for physical damage of the card. 

(b) At a minimum, the card shall achieve at least a mean 10,000 
transactions before card failure. 

(c) The Contractor shall provide the Contract Administrator with 
guidelines on verification of a card failure. 

(d) The mean defect rate for cards received in inventory shall be no 
greater than 0.1%. 

(e) The Contractor shall replace all defective cards at no charge 
immediately upon notification. If defective card problems persist, 
the Contractor shall also provide a written report detailing the 
technical explanations behind the causes of the problem, and shall 
correct the problem within 30 days after determination of cause. 

(f) The Contractor shall provide the Agencies with an option to switch 
to a different card supplier for further issuance at no additional 
charge to address reliability issues in a timely manner. 

2.3.2 Useful Card Life 
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For all Agency issued cards, the fare card shall last the earlier of four (4) 
years or 10,000 transactions as stated in 2.3.1 “Card Reliability” when 
used on a daily basis under normal circumstances for fare payment. 

(a) In the event the card graphics are a critical security feature, the 
graphics shall not deteriorate for at least three years when used on a 
daily basis under normal circumstances for fare payment. 

(b) If the RFCS application is loaded on a non-RFCS issued card, then 
the card life may be that of the card as established by the third 
party card issuer. 

(c) The pre-printed design common to all cards shall be sealed under a 
clear plastic laminate to protect the image. 

6.111-2.4 Physical Requirements - Fare Card 

2.4.1 Physical Standards 

All fare cards shall conform with the following: 

(a) Basic physical standards as defined by the International Standards 
Organization (ISO) standards 7810 and 7813. Dimensional 
thickness and physical robustness standards shall not apply to 
disposable cards, provided that height and width dimensions are 
met. 

(b) Specific physical standards for contactless integrated circuit 
proximity remote coupling cards specified in ISO 14443-1 at the 
time of the Final Design Review. In instances where this emerging 
standard (ISO 14443) modifies or constrains other ISO standards in 
order to accommodate the contactless functionality, such 
modifications shall apply to the fare cards. 

2.4.2 Card Memory Storage Capacity 

At a minimum, the memory storage capacity shall be sufficient to support 
all RFCS functions and shall ensure that the card has sufficient memory to 
store at least two other applications similar in size to the RFCS 
application. 

(a) The Contractor shall choose and specify the memory capacity of 

the fare card given the requirements specified herein and according 
to the Contractor’s analysis of those data and system requirements 
including the anticipated addition of RFCS and non-RFCS 
applications to the card. 
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2.4.3 


(b) The Agencies reserves the right to use the remaining memory on 
Agency issued fare cards for purposes not identified at time of 
Contract award. 

Data on the Regional Fare Card 

The following minimum data segments shall be provided on the card (DR 
101.05): 

(a) Base Segment 

(b) Agency Data 

(c) RFCS Stored Value Purse 

(d) Pass (one or more) 

(e) 10 Day Passes 

(f) Ride History 

(g) Revalue History 

The way data is stored on a fare card is not specified. 
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2.4.3.1 Base Segment (One Per Card) 

The base segment identifies common transit payment data, is applicable to 
each transaction record and shall consist of the following minimum data 
fields: 


Data Field 

Comments 

Card Serial Number 

Regional Fare Card-assigned number 

Card Expiration Date 

Based on life of card 

Value loading restriction code 

Identifies parameters such as minimum payments, max. stored 
value permitted on card 

Customer Zone Fare Preference 

Preset 

Parameter that indicates the customer’s preference for number of 
zones of travel in a multi-zone system (e.g. 1, 2 or 3). 

Functionality to be included, but implemented per Agency policy. 

Fare Category Type Indicator 

Adult, RRFP, youth or other category 

RRFP Type Indicator 

Senior, Disabled 

RRFP Expiration Date 

Required for temporary disabled 

Cardholder Birth Date 

Optional for RRFP cards or youth 


2.4.3.2 Agency Data (One Segment Per Agency) 


Certain Agencies want to collect running totals of daily and/or monthly 
fare amounts paid to enable special fare arrangements or discounts to be 
applied according to usage rate. 

(a) This feature shall be transparent to the customer. 

(b) The Agency Data shall consists of the following minimum data 
fields:. 


Data Field 

Comments 

Amount of Current day’s fare 
(cumulative) 

Optional by Agency 

Amount of cumulative month's fares 

Optional by Agency 

Amount of cumulative 30 day fares 

WSF requires both a 30 and 90 day period 

Amount of cumulative 90 day fares 

WSF requires both a 30 and 90 day period 

Auto-Load 


Guaranteed Ride Home 


Frequent ride counter(s) 

Automatic reset after Agency-defined number of rides. 

Ride counter timer(s) 

Automatic reset after Agency-defined period. 
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2.4.3.3 RFCS Stored Value Purse (One Per Card) 

If a card has an RFCS stored value purse, monetary value will be added by 
the add fare process and subtracted through fare calculations. The RFCS 
Stored Value Purse shall consist of the following minimum data field: 


Data Field 

Comments 

Stored Value Purse 

Limit to be determined by the Agencies 

Remaining Value on Card 

Current stored value remaining on card. 


2.4.3.4 Pass (For Each Pass Type) 

A card may be loaded with one or more passes. The number of passes is 
only limited by card memory capacity. Only one pass type may be 
currently active for an Agency. The Pass Purse shall consists of the 
following minimum data fields: 


Data Field 

Comments 

Agency 

Agency who issued pass 

Start Date of Pass 

First date for rides 

Expiration Date of Pass 

Last date for rides 

Type of Pass 

e.g. Day Pass, 1 week, 2 week. Monthly, Annual, Employer, 

Campus, Puget Pass 


2.4.3.5 10 Day Passes (Trips or Rides) Purse 

A card may be loaded with one or more blocks of stored passes, rides or 

trips such as Sounder’s ten individual day-passes. 

(a) The number of stored ride blocks will be limited only by card 
capacity. 

(b) Only one “electronic book” of stored passes, rides or trips may be 
currently active per Agency. 

(c) The 10 Day Passes Purse shall consists of the following minimum 
data fields: 


Data Field 

Comments 

Agency 

Agency who issued stored rides 

Ride Qualification Code 

Agency dependent code to handle zones or other ride qualifiers 

Remaining Rides or Day Passes 


Expiration Date for Stored Rides 

Last date for ride 
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2.4.3.6 Ride History (Last Ten Rides Per Agency) 

Each time a card is tagged for a new ride, a record is created and the oldest 
record shall be purged. 

(a) The card shall have sufficient capacity to store ten rides for each 
Agency. 

(b) The Ride History shall consists of the following minimum data 
fields: 


Data Field 

Comments 

Agency Providing Service 

Agency providing ride 

Route/Run/Trip 

Route, run, and trip code as applicable to Agency 

Entry Transaction Location 1 

e.g. coordinates from GPS or AVL code 

Entry Transaction Location 2 

e.g. coordinates from GPS or AVL code 

Entry Transaction Location 3 

e.g. coordinates from GPS or AVL code 

Ride date 


FTP Number 

FTP ID number 

Time of Transaction 


Amount of Transaction 

Amount decremented from stored value of the card for current ride 
or transfer 

Transaction Code 

Ride. Reversal, Transfer, Short-payment (fare), Upgrade Fare, 
Exception, including any combination thereof (e.g. pass 
transaction with stored value upgrade). 

Terminal Exit Transaction 

(Optional) exit FTP ID number 

Time of Exit 

(Optional) 

Exit Transaction Location 

e.g. coordinates from GPS or AVL code 


2.4.3.7 Revalue History (Last Five Value Adds) 


Same as the ride history, each time a card is revalued with a new value or 
pass, a revalue record is created and the oldest revalue record is purged. 

The Agency Segment shall consists of the following minimum data fields: 


Data Field 

Comments 

Revalue Type 

Initial value, value add, pass, stored rides, adjustment 



Revaluing Entity 

Agency or Contractor selling value 

Terminal ID of Purchase 


Purchase Date 


Time of Purchase 


Amount of Revalue 
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2.4.4 Graphic Requirements 

All issued fare cards shall conform to a common graphic standard that 
shall be finalized at the final design review. The Contractor shall propose 
a graphics scheme which is consistent with the Agency’s identity 
program. The graphics standard shall be finalized at the final design 
review (DR 101.06). At a minimum, the following elements shall be 
provided on the card: 

(a) A unique serial number shall be imprinted on the front of the card. 

(b) The serial number shall be in conformance with ISO 7812-1 
standards. Its placement will be in conformance with ISO 7811-3, 
as constrained by ISO 14443-1 such as the last line from top/first 
line from bottom is unavailable for embossing because of the 
antenna loop in the card. 

(c) Regional Fare Coordination Project logo. 

(d) Local Agency Customer Service Telephone Numbers shall be 
placed on the back of the card along with customer service related 
information. 

(e) Name of the Fare Card Program shall be imprinted on the front of 
the card. 

(f) An area for a cardholder photo shall be available for post 
production print, to use on Employer, Campus and/or RRFP cards. 

(g) An area for a company logo shall be available for post production 
print, for use with Employer and Campus cards. 

(h) Special Graphics shall be provided if the Agencies choose to issue 
“Collector Cards.” 

(i) An area for a magnetic stripe shall be reserved for interfacing with 
automated teller machines (ATM). 

(j) Card Graphics shall use a minimum of four colors. 

(k) Option Signature Panel shall be provided on the back of the card 
to enable Cardholders to identify to whom the card belongs, or to 
differentiate one fare card from another. 
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6.111- 2.5 Testing Requirements and Procedures - Fare Card 

(a) The Contractor shall validate through the FAT tests that RFCS cards meet all 
the Contract requirements for wear, data retention, and interfaces to terminal 
devices. 

(b) The cards used in FAT shall be RFC production cards representative of those 
to be used in the operational RFCS. 

6.MI-2.6 Security Requirements - Fare Card 

2.6.1 Chip Personalization 

The Contractor shall perform chip personalization during the card issuance 
in the presence of a secure access module (SAM) or another smart card, 
which would hold the encryption key(s). 

2.6.2 Privacy 

Each card application shall be protected with a security key that will 
enable only the owner of the application to view the contents of the 
application information stored on the card. Information pertaining to a 
particular application shall not be accessible by the card issuer or the 
owners of any other application residing on the card. 

6.111- 2.7 Agency or Institution Specific Requirements - Fare Card 

2.7.1 Sound Transit 

The RFCS Contractor shall support Sound Transit fare collection 
equipment contractor with integrating the RFCS application on existing 
fare collection equipment. The RFCS contractor shall, under the 
cooperation of Sound Transit, develop the necessary RFCS software that 
will be loaded onto Sound Transit equipment. It is anticipated that 
software will be required for card to reader interface and CDCS to 
clearinghouse. 

2.7.2 Campus Card Model (University of Washington Husky Card) 

The following requirements shall apply to Campus Cards (DR 101.07), 
specifically to the UW Husky Card. These requirements may also apply to 
large institutional organizations. 

2.7.2.1 Card Imprinting Requirements 

The face of each card shall include space for the following university or 
college-specific imprinted information: 
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(a) University or college logo 

(b) “Non-Transferable Property of {university or college name}” 

(c) Cardholder name 

(d) Classification of cardholder such as Staff, Faculty, Student or 
Affiliate 

(e) Capability of being imprinted with up to four colors 

(f) For student cards only, “Misuse Penalty WAC 478-120 Student 

Conduct Code” 

(g) Cardholder photo 

2.7.2.2 Magnetic Stripe Husky Card 

(a) Cards will be issued with an ABA standard high coercivity 
magnetic stripe (unencoded at issuance) on the reverse side. 

(b) The stripe shall be a maximum .218 in. from top edge of card to tip 
edge of magnetic stripe. Bottom edge of magnetic stripe no less 
than .020 in. from the bottom line of the last track encoded. 

(c) The Signal Output level of all stripes must be equivalent to 80%- 
130% of ISO standard output level specified for 2700-4000 
Oersted stripes (as referenced in ISO Specifications 7811-6). 

(d) The magnetic stripe shall be capable of passing a test to encode 
UW information and then reading the information in several 
different types of readers on campus. 

(e) The magnetic stripe is to be used for campus applications. Use of 
the stripe for other applications or purposes is subject to approval 
by the Contract Administrator and the University of Washington. 

2.7.2.3 Barcode Requirements Husky Card 

(a) Cards shall include a cardholder-specific barcode on the face of the 
card for library and other applications. 

(b) Information to be included in the barcode shall be provided by 
UW. 

(c) The number of the barcode shall be in eye-readable format under 
the barcode, consisting of a combination of sixteen (16) digits and 
spaces, with a margin of clear space at each end of the barcode 
measuring no less than 3/16 of an inch. 
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(d) Barcodes shall have fifteen (15) digits and conform to the 
CODABAR print specifications issued by Pitney Bowes’ Monarch 
marking systems and titled “The Monarch CODABAR Code for 
Identification and Control”. 

(e) The barcodes should be read accurately with one stroke of the 
Intermec light wands Models 1271 or 1281A02 attached to the 
Intermec Wedge Reader 9710 at least 95% of the time. 

(f) The Contractor shall test preprinted cards to assure compliance and 
shall provide the UW with information regarding the method of 
quality control used. 
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6.111- 3 General Requirements Fare Transaction Processor (FTP) 

The requirements stated in this Section shall apply to all configurations of fare 
transaction processors supplied under this Contract as described in Section 6.HI-4, 
6.III-8 and 6.HI-9; but also, as applicable, to the related modules described in Section 
6.IH-6, 6.HI-7 and 6.IH-10. 

6.111- 3.1 Subsystem Description - FTP 

The FTP (DR 102) is the region’s fare collection device for the RFCS. The basic 
functionality of all FTPs is essentially the same, only the physical packaging is 
customized for the environment in which it will be used. In addition to collecting 
fares and validating passes, the FTP shall: 

(a) Store transaction history 

(b) Check for blocked cards 

(c) Perform automated revalue 

(d) Dump all transaction data to the Wireless Data On/Off Loading System, if 
directly connected, when a data transfer is initiated. 

3.1.1 FTP Configurations 

The Contractor shall provide the following FTP configurations that will 
read the data on the fare card, process the corresponding transaction, write 
the correct data back to the fare card, and transfer the transaction records 
to the appropriate data acquisition computer (DAC) or directly to the 
clearinghouse system: 

(a) On-Board FTP (OBFTP) - will be used by all Agencies except 
WSF to process fare transactions aboard buses (Section 6.III-4.) 

(b) Portable FTP - are small, hand held devices used in applications 
where the installation of fixed equipment is impractical or 
unnecessary. Examples include vanpool and paratransit 
applications, WSF operations at selected terminals, and potentially 
on-board commuter and light rail vehicles or at stations. (Section 
6.II-8). 

(c) Stand-Alone FTP - are used primarily in the Sound Transit and 
WSF environments in locations where a fixed, stationary device is 
appropriate. Rail Platforms and Ferry Docks will have multiple 
stand-alone FTPs which will enable passengers to tag the FTP 
associated with their destination (Section 6.III-9.) 
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3.1.2 FTP Configuration Requirements 

All FTP configurations shall include the following elements that are 
described in the subsequent Subsections: 

(a) Central Processing Unit 

(b) Memory 

(c) Smart Card Interface 

(d) Customer Interface 

(e) Hardware Interface 

6.111-3.2 Functional Requirements - FTP 

The following general FTP functional requirements apply to all configurations of 
FTPs. 

3.2.0 Central Processing Unit 

The FTP central processing unit shall be capable of supporting, at a minimum, the 
following functions: 

(a) Prior to use for fare collection or customer service, the FTP shall initialize 
itself and accept log-on from Agency Personnel. 

(b) The FTP shall provide functionality for the following methods of log-on: 

i. Manual entry/update of log-on information through the DDU 
keypad for On-Board FTPs, keypad entry through Portable FTPs, 
and on-line and laptop connection to Stand Alone FTPs. Manual 
log-on and en-route log-on/updates shall not require the use of a 
smart card. 

ii. For on-board FTPs, transfer of log-on information from a driver ID 
card. For Stand Alone FTPs, log-on information shall be 
transmitted through the communications network. 

(c) Specific data to be entered/uploaded for log-on will vary by agency and will 
be defined at Conceptual Design Review (CDRL 1). As a minimum, FTP log¬ 
on data fields shall include: 

i. Fareset 

ii. Trip Number 

iii. Route Number 

iv. Run Number 
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v. Operator ID 

vi. Capability of accommodating minimum two additional fields (to 
be defined for each Agency as part of CDR) 

(d) The Contractor shall be responsible for developing interfaces in the RFCS 
capable of accepting ASCII files of log-on data from Agency run cutting and 
scheduling systems, tied to Operator ID, for the purpose of upload through the 
RFC system. The Agencies will be responsible for providing the format and 
content of the data and identifying the run cutting and scheduling system to be 
used at Conceptual Design Review (CDRL 1). The Agencies will also be 
responsible for modifications to legacy systems to support data export and 
interface to the RFCS. 

(e) Upon reading a card for fare payment, the FTP shall: 

i. Indicate if the card is valid. A blocked or improper card shall trigger a 
red light on the customer display and an audible warning. 

ii. Display the fare to be deducted and fare basis (e.g. “1 Zone Fare”). 
The fare basis display is required if the Cardholder has a Zone Fare 
Preset established on the card. 

iii. If additional fare is required, display the additional amount. 

iv. Make the appropriate deduction, considering any discounts 
applicable, and update any appropriate trip counting data fields. 

v. Display the remaining value on the card and display an indication of 
special fare or pass type, if used, and any frequency discount which 
has accrued. 

(f) The FTP shall store and process the transaction data for upload to the DAC. 

(g) Using displays, light indicators, and audio tones, the FTP shall provide 
operator and customer feedback for each transaction. 

(h) The FTP shall maintain collected transaction data in the event of a device, 
interface, or power failure. 

(i) The Contractor shall provide a method to ensure the integrity of the data on 
the OBFTP until a successful data exchange with the WDOLS is 
acknowledged. 

(j) The FTP shall store and process a minimum of two (2) fare tables: Current and 
those for the next fare or service change. Fare tables shall contain data for a 
minimum two (2) Agencies, with the active table determined by the transit 
service the coach is operating under. 

(k) The FTP shall automatically implement fare table transitions for scheduled 
fare changes, holiday fare tables, etc. 
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(1) The FTP number, agency owning coach, coach number, and service operated 
under shall be parameters that are retained in the FTP unless modified by the 
system administrator/manager. 

3.2.1 Memory 

3.2.1.1 Capacity 

(a) The FTP shall use solid state memory with sufficient capacity to 
store at a minimum, all data subsequent to the last data upload to 
the DACS including: 

i. Up to 10,000 transaction records. 

ii. 100 log-in / log-off records. 

iii. 100 Event records such as, but not limited to FTP 
malfunctions, failed read attempts, successful and 
unsuccessful data up- and down-loads. 

iv. 6,000 bad card numbers for cards issued to the general 
public. 

v. Card block or status change information for all campus and 
other institutional cards in circulation (capacity is required 
to update the status of all campus cards at an academic 
quarter or semester change, and also to update non-campus 
institutional account cards). 

vi. Secret keys for communication and card access. 

vii. Manager passwords. 

viii. Minimum of two (2) fare tables. 

ix. Automatic card revalue information. 

x. Vehicle identification number or designated location code 
to be programmed at time of installation. 

xi. Additional Agency specific data required for processing 
and reporting local fares and inter-service transfers. 

(b) As transaction volumes increase, FTP memory shall be expandable 
to a capacity of at least five times that for previously listed items i. 
through xi. 

(c) The Contractor shall provide data storage for the OBFTP which 
uses non-volatile memory. 

3.2.1.2 Captured Ride Data 

Ride data is captured in the FTP when cards are tagged by customers. The 

data is recorded in groups, called intervals. Using the data fields identified 
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below and additional fields if necessary, the FTP shall capture and/or 
generate the following data. 

(a) Transaction Header Data (for each recording interval) 

Each interval shares common header data, which applies to each 
transaction in the group. An interval may represent one direction of 
a route (e.g. inbound or outbound or ferry route destination), an 
individual vehicle stop, change in log-on or route/run/trip 
parameters, or it may represent a period of time at a fixed location. 
An example of the possible transaction header data is subsequently 
shown. 


Data Field 

Comments 

Agency Owning Coach 

The agency who owns the coach and FTP. 

Coach Number/Designated 
location code 


FTP Number 


Driver/Seller/Attendant 
Log-on 


Service Operated Under 

Community Transit and King County coaches may be operated as Sound 

Transit contracted service, and/or a private contractor may operate as an 

Agency service. 

Fareset 

The fareset in effect 

Transaction Location 1 

Station 1 or Ferry Terminal 

Transaction Location 2 

Station 2 (if applicable). Route or Vehicle Stop 

Route 

Route number as applicable to each Agency. 

Run 

Run number as applicable to each Agency. 

Trip 

Trip number as applicable to each Agency. 

Service date 


Time of Interval Start 



(b) Transaction Detail (for each captured ride transaction) 

The Transaction Detail shall capture and include the data fields 
listed in Section 2.4.3.1 through 2.4.3.6 (current ride only) in each 
transaction. The Transaction Detail shall also include the following 
additional data fields in each transaction. 


Data Field 

Comments 

Driver/Seller/Attendant 
Log-on 


FTP Number 


Date of Transaction 


Time of Transaction 


FTP Transaction ID 

Transaction sequence number generated by FTP 
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The following set of data fields shall be provided but requires fare policy 
decision for activation. 


Data Field 

Comments 



Terminal Exit Transaction 

Optional by Agency, exit FTP ID 

Time of Exit 

Optional by Agency 

Exit Transaction Location 

Optional by Agency, e.g. GPS or AVL 


3.2.2 Smart Card Interface 

The FTP contactless interface shall meet ISO 14443, parts 2 and 3, and 
shall be in conformance with its most recent release at the time of contract 
execution. Where available from the card manufacturer, the FTP 
contactless interface shall meet ISO 14443 part 4, and shall be in 
conformance with its most recent release at the time of contract execution. 

(a) Power and Signal Interface Standards — The Contractor shall 
conform to the standards for contactless cards specified in ISO 
14443-2. 

(b) The FTP shall have a communications signal interface that 
conforms with both ISO 14443-2 Type A and ISO 14443-2 Type B 
standards (DR 102.01). 

(c) In itialization and Anti-Collision Protocol 

i. The card and FTP shall accommodate an anti-collision 
protocol preventing erroneous processing when more than 
one card is simultaneously brought within the processing 
range of the FTP. 

ii. The initialization and anti-collision protocols shall conform 
to the specifications of ISO 14443-3. 

iii. In the absence of such a protocol, the Contractor shall 
propose a standard subject to Contract Administrator 
approval. 

iv. Optional: Through operator intervention, such as holding 
down a designated button, an FTP shall be able to process a 
stack of up to five (5) fare cards. This feature is of interest 
to Washington State Ferries to support vehicle-level 
operations where multiple cards may be presented 
simultaneously. This manual override of the anti-collision 
protocol shall be subject to the review and approval of the 
Contract Administrator. 
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(e) The fare card transaction protocol shall conform to the 
specifications of ISO 14443-4, subject to a compliant interface 
being provided by the card manufacturer. 

(f) Operating Range 

i. The card and FTP shall interface within the distances and 
relative orientations defined in ISO 14443. 

ii. RFCS equipment read-write distance shall be adjustable 
from zero to the maximum defined in ISO 14443. 

iii. The distance shall be optimized once the system is in 
operation. 

3.2.3 Customer Interface 

The Contractor shall provide a customer interface and display (DR 102.02) 

to provide the customer with transaction status information as follows: 

(a) Message indicating the FTP is not operational such as, “OUT OF 
SERVICE”. 

(b) The Contract Administrator will define the message sets and 
formats with the Contractor during the design review process. 

(c) The message sets shall be finalized after the Beta Test program has 
been completed. 

(d) Display messages shall be easily edited on an as needed basis, once 
the system is in operation. 

(e) At a minimum, the following messages shall be provided: 

i. Default or idle message to indicate the system is 
operational such as, “READY.” 

ii. Fare type and amount deducted. 

iii. Remaining value on the card. Activation of this feature for 
Full System Rollout shall be finalized after completion of 
the Beta Test program. 

iv. Indication of an unsuccessful transaction with reason such 
as, “Invalid read/encode - try again,” “Insufficient value,” 
“Invalid card - Call Service Center.” 

v. Indicator that the card has a low remaining value such as 
“low value.” 

vi. Message sets customized according to inter-Agency transfer 
agreements and fare policy. 
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(f) The display menu and display messages shall be programmable 
using a developer’s utility, supplied by the Contractor, running on 
a Window s-Intel PC with the capability to upload the modified 
menu or messages to the FTP using a standard PC port. 

(g) The messages and displays shall also be modifiable from a central 
location. 

3.2.3.1 Light Indicator 

(a) The FTP shall be equipped with transaction status indicators 
visible to the customer. 

(b) These indicators shall consist of a “Green-, Yellow-, and Red- 
Light” to indicate a successful or unsuccessful transaction. 

(c) This feature augments the alpha numeric display. Figure III-3.1 
summarizes customer visual indicators. 

3.2.3.2 Audio Indicator 

(a) An audio feedback for indicating the completion of a successful or 
unsuccessful transaction shall be also be provided. 

(b) The audio indicators shall be different sounds or different volume 
levels of the same sound. 

(c) The FTP sound level shall be controlled with a minimum number 
of keystrokes or adjustments by the operator of the relevant FTP. 

(d) The type of audio feedback and the parameters are subject to 
Contract Administrator approval. Figure III-3.1 summarizes 
customer audio indicators. 


Figure 111-3.1 

CUSTOMER INDICATOR MATRIX 


Condition 

Visual Indicator 

Audio Indicator 

Successful Transaction 

Green 

Indicator 1 

Warning - i.e. low card value 

Yellow 

Indicator 2 

Incomplete or failed read 

Yellow Flashing 

Indicator 3 

Unsuccessful Transaction - i.e. 

Red 

Indicator 4 

insufficient value, expired pass, blocked 



card 
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6.111-3.3 Performance Requirements 

3.3.1 Processing Time 

The processing of a transaction shall be completed within 0.3 seconds 

(300 ms). The following shall be concluded within this time frame: 

(a) Initialization; 

(b) Authentication and other security processes; 

(c) Data Exchange (read and encode); 

(d) Computation of fare, including applicable incentives or discounts; 

(e) Display of results on the customer (and any other applicable) 
displays. 

3.3.2 Accuracy and Reliability 

(a) Accuracy for all types of FTPs is defined as the mean ratio of the 
number of transactions correctly recorded by the FTP, as evidenced 
by the transactional data recorded and stored on the fare card, to 
the number of transactions attempted. 

(b) As part of Factory Acceptance Testing (Section 6.II-11.4.2) and 
Acceptance Testing (Section 6.II-11.4.7), the Contractor shall 
demonstrate a minimum FTP transaction processing accuracy rate 
of 99.99% as identified in Item (a) above. 

(c) The FTP shall have a minimum reliability of 30,000 MOHBF for 
each type of FTP configuration. 

(d) Any single FTP that fails more than two (2) times per month as a 
result of Type II failures as defined in Section 6.11-11.4.8.7.2, 
subsections iii, iv and v, shall be replaced with a new unit. If the 
new unit experiences the same failure rate, the Contractor shall be 
responsible to initiate an investigation to determine why the unit 
fails, and then shall perform repairs, or redesign the unit as 
necessary and replace the existing units with the redesigned units. 
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6.111-3.4 Physical Requirements 

3.4.1 Appearance and Styling 

(a) Each type of FTP shall conform to generally accepted practices in 
appearance and styling, within the limitations of materials used for 
construction, and shall be approved by the Contract Administrator 
at the Preliminary Design Review. (DR 102.03) 

(b) All exterior surfaces shall be clean with all comers rounded. 

(c) There shall be no exposed bolt heads, nuts, sharp edges, or cracks 
on the outside surfaces. 

(d) All displays shall be flush mounted in the enclosures. 

3.4.2 Structural Features 

(a) The finish shall be orbital finished stainless steel, unless specified 
otherwise or approved by the Contract Administrator. 

(b) Provisions shall be incorporated to drain any liquids that may enter 
the device or condensation that may develop. 

3.4.3 Customer Display 

(a) The display shall be water and liquid resistant. 

(b) Any leakage into the unit shall not cause the unit to become non¬ 

opera tional. 

(c) The display technology shall be subject to Contract Administrator 
approval and shall meet the following requirements: 

i. Readable under any combination of ambient lighting such 
as direct sunlight and night-time operation; 

ii. At least two lines of alpha-numeric text with a minimum of 
twenty characters readable from 6 feet. 

(d) The display shall resist breakage due to accidental impact from 
hard objects, such as briefcases, during boarding, wheelchair 
handles or other devices used by the disabled community. 

(e) WSF will require two customer displays at vehicle toll booths. 

Both displays shall show the same messages simultaneously. 
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3.4.4 

Locks and Security 


(a) 

Access cover(s) of the FTP housing shall be opened with 
mechanical key(s) for maintenance access to the modules and 
subassemblies. 


(b) 

The key(s) shall be of a type that is not readily duplicated and 
stamped with the words “Do Not Duplicate”. 


(c) 

Alternative means of securing the internal components shall be 
subject to Contract Administrator approval. 

3.4.5 

Identification Labels 


(a) 

A metal identification label inscribed with the FTP serial number 
shall be permanently attached to the outside of each FTP housing. 


(b) 

Major subassemblies inside the FTP shall have a permanently 
attached label inscribed with a unique serial number and part 
number prominently located on the subassembly. 

3.4.6 

Modularity 


(a) 

The FTP shall be packaged as a separate unit and not bundled with 
the DDU or WDOLS. 


(b) 

The FTP shall use connectors, approved by the Contract 
Administrator, for all external connections. 

6.111-3.5 Environmental Requirements 

The FTPs and related modules shall be designed to comply with all applicable FCC 
regulations concerning conducted and radiated emissions of RF energy and shall 
operate in the environmental conditions provided in Figure IE-3.2. 

Figure 111-3.2 

FTP OPERATING ENVIRONMENT 


Parameter Minimum Requirement 

Temperature Range: +10°F to +110°F operating; -25°F to +150°F storage 

Thermal Shock: Per SAE J1455 (Jan 88) Section 4.1.3.2 

Thermal Cycle: Per SAE J1455 (Jan 88) Section 4.1.3.1 

Humidity: 20% - 90% relative humidity, non-condensing 

Shock: Up to 5g instantaneous and horizontal 

Vibration:_1,5g (RMS), 5 to 200 Hz_ 
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Parameter 

Minimum Requirement 

EMI Susceptibility: 

Example sources: Heater 
and air conditioning 
controls, high voltage 
arcs, alternators, radar 
and radio from WSF 
operations, etc. 

Per the requirements of 6.ill-1.7.1 (h). 

Other (dust, grit, rain- and 
salt water protection): 

The FTP and associated devices shall have the following 
minimum ratings against the ingress of dust, grit and water: 
Onboard FTP (6.ill-4), Driver Display Unit (6.ill-6), and Radio 
Control Unit (6.ill-6.8.3) 

Wireless Data On/Off Load System (6.ill-7): IP 42 rating in its 
installed configuration, to be confirmed at Final Design 

Review. 

Stand Alone FTP (6.ill-9): IP 55 

Portable FTP (6.ill-8): IP42 

The Stand Alone FTP shall include additional protection to 
prevent salt water ingress and corrosion when installed in a 
marine environment (e.g. for WSF). This shall include 
protection against direct salt water spray. 


6.MI-3.6 Data Exchange Requirements 

All software and fare table updates shall be uploaded through the RFC system, and 
shall not require manual data upload from a laptop computer, memory card, disk or 
other means. 

The FTP clock shall be synchronized via the LonWorks port, if available on 
LonWorks, or with the DACS clock if not available on LonWorks. If the DACS 
clock is used, synchronization shall occur during data on and off loads. 

3.6.1 Communication Ports 

(a) The FTP shall include as a minimum the following ports: 

i. A high speed serial port to provide the primary data connection to 
the FTP. 

ii. An RS232 port for diagnostics and back-up data transfer. 

iii. A LonWorks port for interconnection with other LonWorks 
devices. 

(b) The Contractor shall provide a Communications Interface Specification 
(DR 102.04) for the FTP. This specification shall include a description of 
the data elements and communication protocols for all ports. 

(c) The Communications Interface Specification shall also describe the data 
elements and communications protocols for any additional communication 
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ports required by specific FTP configurations per Sections 6.III-4, 6.III-8, 
and 6.HI-9. 

3.6.2 FTP Back-Up System 

(a) The Contractor shall provide an alternate means of extracting data 
from the FTP, such as via a laptop computer, subject to Contract 
Administrator review and approval. 

(b) The backup system shall be used primarily to upload captured 
transaction data from the FTP. 

(c) It shall be possible to manually upload/download data files in the 
event of a device or interface failure through an RS232 port. 

(d) In the event of a primary data storage failure or backup battery 
failure, an indication on the display shall alert the operator. 

(e) Correct password entry shall automatically enable the FTP to 
download the transaction data to the back-up device. 

i. Neither the FTP nor the backup device shall retain the 
correct password. 

ii. Unsuccessful attempts to enter the password shall be logged 
at the FTP. 

iii. The log shall contain detailed information including, the 
date, time, location, FTP number, and erroneous password. 

(f) An alternate process for initiating data extraction may be provided 
which shall be subject to Contract Administrator review and 
approval. 

(g) Alternate means of removing data records may be provided. 

i. The Contractor shall provide a detailed description and the 
technical details necessary for Contract Administrator 
evaluation. 

ii. Alternative means of data removal are subject to Contract 
Administrator approval. 

(h) If the FTP is removed for depot maintenance, the backup method 
shall upload captured transaction data to a depot DAC or to the 
clearinghouse. 
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6.111-3.7 Testing Requirements and Procedures - FTP 

In addition to testing specified in Section 6.II-11.4 “Testing Requirements” the 

following tests shall be performed. 

3.7.1 Cycling Test 

Cycling test for each type of FTP shall be performed as follows on the first 
unit representative of the production units. 

(a) A minimum of 10,000 transactions, and at least 500 data 
downloads and 200 fare table up-loads shall be conducted. 

(b) Transactions shall be divided evenly among all possible fare 
deduction and Agency transfer transactions of which the device is 
capable. 

(c) The fare amounts shall be representative of those expected to be 
employed in the RFCS. Detailed information regarding the 
transaction types and values to be used in the cycling test shall be 
included in the Detailed Test Procedures and subject to Contract 
Administrator approval. 

3.7.2 Vibration Test 

The Contractor shall ensure that all vehicle fleet vibration conditions 
expected in the area of equipment installation are taken into account to 
ensure that proper isolation/protection is built in to the design of 
equipment that may be used in an on-board environment to accommodate 
the range of frequencies anticipated for the vehicle fleet. The following 
requirements shall be met. 

(a) The FTP components shall be tested per the procedure of MIL- 
STD-810C, Method 514.2, Category f Cun’e V(1.5g, 5.5 to 200 
Hz) with the following changes: 

- The cycling time shall be two (2) hours on each axis for a 
total of six (6) hours. The equipment shall operate normally 
during and after this acceleration test, and shall not 
experience broken or loosened parts from this vibration. 

- At the conclusion of each axis frequency sweep cycle, the 
equipment shall be subjected to a vibration of three (3) g- 
forces at a frequency sweep between seven (7) and fourteen 
(14) Hz for a period of one (1) minute and four (4) g-forces 
at a frequency sweep between seventy (70) and one hundred 
and forty (140) Hz for a period of one (1) minute. The 
equipment shall operate normally after these acceleration 
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tests and shall not experience broken or loosened parts from 
this vibration. 


3.7.3 Shock Test 

The FTP equipment shall be tested per Procedure 1 of M1L-STD-810C 

with the following changes: 

(a) The half sine shock pulse shall have a peak value (A) of 5g and a 
duration (D) of 20 milliseconds. 

(b) The on-board equipment shall operate normally after the shock 
tests and shall not have experienced broken or loosened 
components as a consequence of these tests. 

6.111-3.8 Additional Security Requirements - FTP 

The Contractor shall provide a means to prevent unauthorized tampering with a stolen 

or lost FTP and Related Modules. 

(a) The Contractor shall design the FTP to prevent unauthorized recovery of 
electronic value stored in the memory, or “reverse engineering” which would 
compromise the RFC system security. 

(b) Upon loss or disconnection of power, the FTP shall securely power down and 
retain all data. 

(c) Each type of FTP shall be provided with a non-volatile memory for storage of 
the data files for at least 72 hours as described in the System Backup Plan 
(CDRL 5). 
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6.111-4 On-Board Fare Transaction Processor (OBFTP) 

6.MI-4.1 Subsystem Description - OBFTP 

The Contractor shall provide On-Board Fare Transaction Processors (OBFTP) 
allowing fare cards to be read and encoded through the contactless interface during 
the fare payment process on-board Agency buses. The OBFTP shall consist of a 
CPU for processing transactions, memory for storing fare tables and transaction 
records, customer display, and card reader (DR 102.05). 

The OBFTP shall be capable of operating, when delivered, in a limited integration 
mode or as a plug-n-play peripheral (full integration mode) on an on-board network to 
be provided by others. Initially, the Agencies expect to operate the OBFTPs with a 
limited degree of integration, and then migrate to a full integration mode when an on¬ 
board Vehicle Logic Unit (VLU) is developed and installed by others (see Section 
6.m-5). 


A flexible architecture for the OBFTP (DR 102.06) is required to allow each agency 
to migrate from the limited integration mode to the full integration mode at any time 
in the future, and to accommodate on-board integration requirements that vary by 
Agency. The OBFTPs, when delivered, shall be capable of supporting the following 
two modes of operation, and shall be designed to allow migration from limited to full 
integration mode without hardware or operating/RFCS application software changes. 

4.1.1 Limited Integration Mode (LIM) 

In the Limited Integration Mode, the OBFTP shall store transactions until 
communication with the WDOLS is established and data transfer can be 
completed. The OBFTP shall connect to other on-board devices as 
illustrated in Figures III-4.1 and III-4.2. 
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Figure 111-4.1 

OBFTP ARCHITECTURE for LIM 



Figure HI-4.2 identifies the module interfaces that apply to the Limited Integration 
Mode (LIM). 


Figure 111-4.2 

MODULE INTERFACE SUMMARY - LIM 


Module 

DDU 

WDOLS 

VLU 

Radio 

Control Unit 

GFI Farebox 
(Option) 

OBFTP 

Ethernet/High 
Speed Serial 

N/A 

N/A 

N/A 

N/A 

DDU 


Ethernet/High 
Speed Serial 

N/A 

J1708 

J1708 

WDOLS 



N/A 

N/A 

N/A 


4.1.2 Full Integration Mode (FIM) 

In the Full Integration Mode, when the VLU is available (provided by 
others), the OBFTP shall send transactions as they occur to the VLU for 
subsequent offloading to the WDOLS. The OBFTP, DDU and WDOLS 
shall be connected as illustrated in Figures III-4.3 and ni-4.4. 
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The LonWorks interface between the OBFTP and VLU shall be used to 
accept time, date and (if available) location data, trip changes, fareset 
changes and synchronization. An Ethernet/High Speed Serial interface 
shall be used for on/off-loading data via the WDOLS. The VLU will 
tunnel RFCS data from the OBFTP to the WDOLS. 

Figure 111-4.3 

OBFTP ARCHITECTURE for FIM 



Figure III-4.4 identifies the module interfaces that apply to the Full Integration Mode 
(FIM). The Contractor may suggest alternative on-board configurations in addition to 
the configuration provided, subject to the review and approval of the Contract 
Administrator. 
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Figure 111-4.4 

MODULE INTERFACE SUMMARY - FIM 


Module 

DDU 

WDOLS 

VLU 

Radio 

Control Unit 

GFI Farebox 
(Option) 

OBFTP 

N/A 

N/A 

Ethernet/High 
Speed Serial 

+ 

Lon Works 

N/A 

N/A 

DDU 


N/A 

Ethernet/High 
Speed Serial 

+ 

J1708 

J1708 

J1708 

WDOLS 



Ethernet/High 
Speed Serial 

N/A 

N/A 


6.111- 4.2 Functional Requirements - OBFTP 

The following functional requirements supplement those stated in Section 6.III-3.2. 

(a) The OBFTP shall accept driver input through the Driver Display Unit (DDU) 
for security, data collection, and operational purposes. 

(b) The OBFTP shall transfer data to and from the DAC via a wireless off/on 
loading system, Section 6.III-7. 

(c) The OBFTP shall include capabilities to accept and transfer to the DDU log¬ 
on data (driver ID, and initial route, run, block, trip, starting fareset and other 
log-on data) from a driver smart card. 

6.111- 4.3 Performance Requirements - OBFTP 

The following performance requirements supplement those stated in Section 6.III-3.3. 

(a) The placement of the OBFTP shall promote an accelerated throughput of 
passengers. 

(b) The minimum throughput rate for OBFTP shall be 30 passengers per minute. 

(c) The throughput rates assume passengers familiar with system operation with a 
valid fare card, no mis-reads or cards with insufficient value, and no automatic 
revalue. 

(d) The Contractor shall conduct a human factors analysis with regard to the 
placement of the OBFTP and confirm the results of the analysis through the 
human factors test in accordance with Section 6.II-11.4.1. 

6.111- 4.4 Physical Requirements - OBFTP 

The following physical requirements supplement those stated in Section 6.III-3.4. 
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4.4.1 Dimensions and Layout 

A prototype of each OBFTP configuration and its mounting (DR 102.07) 
shall be demonstrated at time of PDR on each Agency bus type mounting 
location. Access to the vehicles will be coordinated through the Contract 
Administrator. 

4.4.2 Structural Features 

(a) All on-board equipment provided under this contract shall resist 
shocks equal to 5.0g without permanent deformation or failure of 
mounts or diminution of operational characteristics of any 
subsystems. 

(b) The OBFTP enclosure shall be stainless steel or approved 
alternative subject to the approval of the Contract Administrator. 

6.111- 4.5 Electrical Requirements - OBFTP 

Equipment installed on-board transit vehicles shall meet the following power supply 
requirements: 

(a) Nominal voltage: 12 to 24 volts DC nominal (car or bus battery) 

(b) Operating range: 9 to 39 volts DC 

(c) Equipment shall be able to withstand sustained voltage levels of up to 48 VDC 
for up to ten (10) minutes. 

(d) Equipment shall not suffer damage or lose data in memory when the supply is 
increased to 48 VDC. 

(e) Equipment shall not suffer corruption of data when the power dips below 
9 VDC. 

(f) Equipment shall not be damaged by very high (twenty [20] times nominal 
voltage) short duration (up to ten [10] milliseconds) peak voltage. 

(g) Contractor shall indicate full operational and quiescent power drain for each 
on-board module proposed. 

6.111- 4.6 Data Exchange Requirements - OBFTP 

The following data exchange requirements supplement those stated in Section 6.III- 
3.6. 

(a) To the extent possible, data communications between the OBFTP and other 
on-board devices shall comply with the applicable Transit Communications 
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Interface Profiles (TCIP) standards that are in effect at the time of Notice to 
Proceed. 

(b) Communications between on-board devices shall be as described in Section 

6.m-4.1. 

(c) The Contractor shall provide the drivers and the interface software for the 
OBFTP, and shall provide an interface specification for future connection to a 
VLU. 

(d) The OBFTP shall include a diagnostic port and have the capabilities to allow 
configuration changes and system maintenance activities to occur through the 
use of a laptop computer. Any configuration changes and/or system 
maintenance activities conducted shall be accounted for in the FTP memory 
and a record shall be transferred to the clearinghouse during the next fare card 
transaction data transfer. 

(e) The OBFTP shall include the ability to interface with a commercially 
available Global Positioning System (GPS) through an available port, and tag 
transactions with location information. 

6.111-4.7 Installation Requirements - OBFTP 

The Contractor shall work with designated staff from each Agency to determine on¬ 
board equipment location and installation restrictions, requirements and 
configurations. The joint consultation will include a prototype installation on each 
vehicle type in each Agency’s fleet as described below. Any RFCS equipment 
mounted in a vehicle is subject to review and approval of the relevant Agency. Any 
modifications to existing stanchions or equipment (e.g. fareboxes) must be approved 
by the affected Agency. 

(a) All mounting hardware associated with the OBFTPs shall be provided by the 
Contractor. 

(b) Available mounting options shall include as a minimum: mounting on vertical 
stanchions, mounting above, in front of, or below horizontal stanchions, and 
mounting on horizontal or vertical dash or other flat surfaces. 

(c) The mounting hardware and the OBFTP shall be positioned such that it 
minimizes encroachment on the passenger and the driver, and does not 
obstruct the driver’s right mirror field of vision and view to the right front of 
the bus including the view of the front door. 

(d) The OBFTP mounting location shall allow ease of driver entry and exit from 
the driver’s compartment with no risk of injury such as knees. 
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(e) The Contractor shall provide a flexible mounting system that allows the 
mounting location to be optimized, maximizing passenger throughput and 
driver operability and comfort. 

(f) The Contractor shall provide measurements and schematic drawings of any 
required stanchion modifications for each vehicle type and stanchion 
configuration. 

(g) Equipment installation shall be prototyped for each coach type at each 
Agency. The Contractor is advised that although similar coach types are in 
use at different Agencies, the interior configuration may be different. At a 
minimum, the prototyping process shall be as follows: 

i. At Conceptual Design Review, the Contractor shall supply each 
Agency with a set of typical brackets, mounting hardware, and 
wiring such that Agency staff can test alternative equipment 
configurations. 

ii. At Preliminary Design Review, the Contractor shall conduct a site 
survey of all coach types at each Agency, and working with 
Agency staff identify preferred installation, mounting and wiring of 
onboard equipment for each coach type. 

iii. At Final Design Review, the Contractor shall finalize all mounting 
hardware, subject to approval by the Agency impacted. At the 
discretion of each Agency, final design shall be based on a) an 
Agency provided prototype or mock-up of the hardware, b) the 
Agency providing design details or drawings describing preferred 
installation, or c) the Contractor generating design details and 
recommendations. In any event, the Contractor shall be 
responsible for the preparation of all final design and fabrication 
documentation, molds, prototypes, and other materials required for 
equipment installation. 

iv. Upon fabrication of the first article of installation hardware, the 
Contractor shall conduct a site survey of all coach types at each 
Agency to verify the correct design and fabrication of the 
hardware, and confirm suitability. 

(h) The Contractor shall provide fixed mounting hardware. The Contractor shall 
provide adjustable hardware as a Contract Option to be negotiated and 
exercised at the discretion of an Agency. 

(i) Stanchion modifications will be the responsibility of each Agency. 
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6.111-4.8 Rear Door FTP Units (Option) 

The Contractor shall propose an option for the provision of rear-door fare transaction 

processors for Agencies who are considering all-door loading. Rear door FTP units 

shall meet the following additional requirements: 

(a) Rear door FTPs shall meet the installation requirements described in Section 
6.m-4.7. 

(b) Rear door FTPs shall be slaved to the DDU or master FTP at the front door. 

(c) The operator shall not be required to enter additional log-on, parameter change 
or other data to initialize rear door readers or change status. 

(d) The operator shall have the capability of de-activating (turning off) the rear 
door readers from the DDU, independent of the front door reader. 

(e) A consolidated fare transaction data set for all readers on the vehicle shall be 
provided that includes the device ID of each reader. 
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6.111- 5 Vehicle Logic Unit (VLU) - [Provided by others] 

The information about the VLU in this Section is provided for information purposes 
only. 

6.111- 5.1 Subsystem Description - VLU 

The VLU will be installed by others for the purpose of evolving to a fully integrated 
on-board system. This is referred to as the Full Integration Mode (FIM). When 
installed, the VLU will function as the on-board server or central processor. The 
VLU act as the communications interface between the OB FTP and WDOLS, 
tunneling data between the two devices. The VLU will also support multiple, 
concurrent applications such as vehicle location, passenger counting, vehicle 
operating data, stop annunciation and other functions, and will store and buffer data 
from these systems for off-load by the WDOLS. 

As part of the transition from Limited Integration Mode (LIM) to FIM, 

• the WDOLS connection will be moved from the OBFTP to the VLU, and data 
exchange with the data acquisition computer (DAC) will occur through the 
VLU; and 

• the connection to the DDU will be moved to the VLU, and the operator 
interface with the OBFTP will occur through the VLU. 

It is envisioned that the VLU and OBFTP will maintain exactly the same fare 
transaction data file, which will be verified upon data exchange, until cleared with 
instructions from the DAC. The DAC will segregate the data and forward all Smart 
Card transaction data to the clearinghouse. 
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6.MI-6 Driver Display Unit (DDU) 

6.MI-6.1 Subsystem Description - DDU 

The Driver Display Unit (DDU) shall display OB FTP information and provide the 
human interface for interacting with on-board systems. The DDU (DR 103) shall 
consist of a software programmable display with programmable soft keys on the 
perimeter. 

The DDU shall be designed to provide real-time operation and control of a minimum 
of six (6) additional on-board systems or applications. Provided as information in 
Appendix F is an example “Conceptual King County Driver Display Unit Operating 
Concept”. This document provides a conceptual example for King County of how the 
DDU might operate in a multi-application on-board environment. 

In keeping with an open, modular system architecture, the Contractor shall provide a 
DDU that is packaged separately and not bundled with the FTP or WDOLS. 

6.111-6.2 Functional Requirements - DDU 

6.2.1 Keyboard 

The keyboard (DR 103.01) shall provide the human interface with the 

OBFTP and other onboard subsystems. 

(a) The DDU keypad shall provide manual log-on (sign on) and log¬ 
off capabilities per the requirements of Section 6.III-3.2.0, and 
shall include functionality as required to support transfer of log-on 
information via the WDOLS. 

(b) The DDU shall transfer log-on data/changes to all connected 
devices through a single keypad entry or data transfer from a driver 
smart card. The DDU shall not require multiple re-entry of log-on 
data/changes to initialize multiple on-board devices. 

(c) The DDU shall be provided with a minimum of sixteen (16) 
programmable soft keys around the perimeter of the display 
(display keypad). The Contractor may propose a reduced key 
keypad provided that all functionality can be met, subject to 
approval by the Contract Administrator at Final Design Review. 

(d) The driver shall be able to enter fare set/category, fail-back voice 
radio channel, operator identification, run, route or time 
segmentation data and any other agency specific data on the driver 
keypad, either as a primary data entry or as a backup to any vehicle 
location system which may be installed to support this function. 
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(e) The display keypad shall be capable of assigning keys such that 
multiple onboard functions can be controlled on each display 
“page”. E.g. some keys on a display page may be assigned to 
RFCS, while others may be assigned to the radio, PA, or other 
onboard functions. 

(f) The display keypad shall allow a return to the main screen or menu 
from any sub-level screen or menu with one key press. 

(g) The system shall be able to collect transaction data in the event 
incorrect log-on data is entered by the driver, or when no log-on is 
entered at all, the driver shall be alerted through an audible alarm, 
and a flashing message on the driver display. 

(h) The display keypad shall be software programmable, and shall 
allow a driver to conduct, as a minimum, the following smart card- 
related functions: 

i. Override default fare payment parameters upon notification 
by the customer (e.g. override default settings to pay 
multiple fares from one card, pay for a “day pass”, pay for a 
special or promotional fare, pay for a passenger of with a 
different fare basis, pay for a customer traveling a greater 
number of zones than their Zone Fare Preference Preset, 
etc.) 

ii. Conduct a fare transaction reversal (enabled only subject to 
Agency policy). 

iii. Charge an upgrade fare for a customer traveling a greater 
number of zones than their Zone Fare Preference Preset 
after the initial transaction has occurred. 

iv. Operate the farebox and other on-board systems in the FIM 
and FIM modes. 

(i) The display keypad shall be software configurable to /replace 
manual counters used with non-registering fare boxes, providing 
the ability to record non-smart card boardings through keypad data 
entry. 

(k) The display keypad and control logic shall be designed to minimize 
operator keystrokes. High priority functions (as defined by the 
Agencies during Conceptual Design Review) shall be located at the 
top level (first page) of the display. Medium and low priority/use 
functions shall be accessible within 2 additional keystrokes. 
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6.2.2 Display 

The display (DR 103.02) shall allow monitoring of the OBFTP and any 

connected subsystems. 

(a) The message display area of the LCD shall allow monitoring of the 
OBFTP status and mirror the customer display during each 
transaction. 

(b) The message display area of the LCD shall not be overwritten with 
softkey labels except insofar as approved during Conceptual 
Design Review (CDRL 1). 

(c) The display shall serve as the monitor for interfacing with the FTP 
and any other connected subsystems for system maintenance and 
configuration changes. 

(d) The display shall be capable of displaying status information for 
multiple onboard functions simultaneously. E.g. the display may 
simultaneously display fareset, radio information, route-run 
information, etc. 

(e) The display shall display current time in hh:mm:ss format in 
characters sufficiently large to be read by the driver when seated. 

(f) The Agencies will define the message sets and formats with the 
Contractor during the design review process (DR 103.03). 

6.MI-6.3 Performance Requirements - DDU 

The DDU technology shall be subject to Contract Administrator approval and shall 

meet the following requirements: 

(a) Readable in all lighting conditions encountered on a bus during day and night, 
such as direct sunlight or driving in rural areas with limited outdoor lighting. 

(b) The DDU shall have a minimum reliability of 30,000 MOHBF. 

(c) All keys or buttons shall have a minimum life of 10 million actuations. 

(d) The DDU shall continue to function and operate other onboard devices in the 
event of OBFTP failure. 

(e) The DDU shall be self-restarting, and shall not become unresponsive or 
require manual reboots or restarts to continue operation. 
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6.111- 6.4 Physical Requirements - DDU 

The DDU shall meet the physical requirements in Section 6.III-4.4 and the following: 

(a) The DDU shall be designed to be water and liquid resistant, and the enclosure 
shall be water and liquid tight. 

(b) Any leakage into the unit shall not cause the unit to become non-operational. 

(c) The DDU shall resist breakage due to accidental impacts from hard objects, 
such as briefcases during boarding, or wheelchair handles or other devices 
used by the disabled community. 

(d) DDU shall incorporate a back-lighted LCD graphics display with controls to 
turn the backlighting off and on, and vary the intensity of the display. 

(e) The message display area of the LCD graphics display shall be a minimum of 
240x128 pixels (landscape format). 

(f) All softkey assignments shall be displayed outside of the message display area 
of the LCD display. 

(g) The Agencies require the overall size of the DDU to be the minimum feasible 
within these specifications and human factors requirements, as space within 
the driver compartment of the vehicles is very limited. The Contractor shall 
include scale drawings and mock-ups of the proposed DDU showing all 
dimensions. 

6.111- 6.5 Electrical Requirements - DDU 

The electrical requirements specified in Section 6.III-4.5 shall apply to the DDU. 

6.111- 6.6 Data Exchange Requirements - DDU 

(a) The DDU shall contain at a minimum the following interfaces (DR 25) as 
illustrated in Section 6.III-4.1: 

i. One (1) J1708 communications interface. 

ii. Two (2) RS232 communications interfaces for Agency use for 
controlling other devices. 

iii. One (1) RS232 communications interface for diagnostic purposes. 

iv. One (1) Ethernet/high speed serial communications interface. 

6.111- 6.7 Installation Requirements - DDU 

The DDU shall be installed in accordance with the requirements specified in Section 

6.III-4.7 as they apply to a DDU. 
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6.111-6.8 Integration Requirements - DDU 

6.8.1 General Integration Requirements 

(a) The DDU shall be fully integrated with other RFCS subsystems. 

(b) The Contractor shall cooperate and coordinate with Agency staff and other 
vendors to install and integrate additional applications on the DDU, and 
provide integration as described herein. 

(c) The DDU shall be designed to migrate from LIM to FIM integration without 
hardware changes or software upgrade. 

(d) The driver display unit shall have the capabilities to replace the existing King 
County Mobile Data Terminal (MDT) as the universal display/keypad device, 
and shall be adaptable by any agency to accommodate integration with their 
future on-board systems. 

(e) The Contractor shall develop the necessary software to support the on-board 
operations of the RFCS. The Contractor’s software shall be integrated with 
software developed by others that supports existing systems. 

(f) The DDU shall be supplied with all required software tools, documentation, 
simulation and test routines, and other information as required to allow 
modification or the creation/installation of new applications by the Agencies. 

(g) As part of Design Documentation, the Contractor shall provide a fully 
detailed interface control document for all interfaces to third party devices 
(DR 103.04). 

(h) The return state of each on-board system (default state or last active state) 
shall be defined by the Agencies. 

(i) The priority of on-board systems and functions ( assignments and messages on 
the primary and other screens) shall be subject to Agency review and approval 
during Conceptual, Preliminary and Final design. These priorities must be 
modifiable by the Agencies as required. 

(j) The DDU shall be capable of operating multiple on-board systems 
concurrently. These systems must be able to operate in an integrated manner 
(e.g. operate other on-board devices and display their status without 
interrupting fare collection processing and display). 

(k) The DDU shall not require interconnection with the FTP or other onboard 
devices to function. 

(l) Each Agency shall be able to configure key assignments, screen assignments, 
and menu structures independent of that of other Agencies. 
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6.8.2 Electronic Registering Farebox Integration (Option) 

(a) The Contractor shall develop an interface from the DDU to GFI 
registering fareboxes equipped with the 20001 logic board (DR 
103.05), based on an interface specification to be provided by the 
Contract Administrator at Conceptual Design Review. 

(b) The contractor shall develop the hardware, software, and firmware 
required to provide log-on, log-off, en-route trip change and other 
messages from the DDU through a J-1708 interface to the farebox. 

(c) Messages shall be customized for each Agency, and shall include 
as a minimum: 

i. Transmission of log-on messages that include some or all 

of: 

• Operator ID 

• Route 

• Run 

• Trip Number 

• Fareset 

ii. Transmission of log-off messages. 

iii. Transmission of en-route trip change messages that may 

include some or all of the log-on message data parameters 

(d) The DDU shall include the capability of providing multiple 
transmissions/re-tries of a log-on/log-off/trip change message 
without acknowledgment. The number of retries shall be a user 
configurable parameter 

(e) The DDU shall include the capability of registering an 
acknowledgment of a message received. 

(f) The DDU shall provide an additional message consisting of time 
and date information in standard format, to be used for farebox 
synchronization or transaction time stamping. Implementation will 
be at the direction of the Agencies. 

6.8.3 King County Radio Control Unit (RCU) Development and 
Integration (Option) 

(a) The Contractor shall develop a Radio Control Unit for King 
County (DR 103.06) to interface with on-board devices as 
illustrated in Section 6.M-4.1. The primary purpose of this device 
is to operate King County’s legacy radio/AVL system. Additional 
information is contained in Appendix E, and prototype 
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documentation (from a previous project) will be made available 
from King County at or prior to Conceptual Design. 

(b) The RCU shall enable existing King County Mobile Data Units 
(MDU) to interface to the legacy 450 MHz GE Delta-S radio and 
current model Motorola or Ericsson 450 MHz radios. 

(c) The Contractor shall develop a production version of the RCU 
based on a current King County prototype. Work activities shall 
include: 

i. DDU-RCU design and software interfaces. 

ii. Obtain test bench equipment (to be provided by KCM): 

• GE Delta-S radio 

• MDU (Mobile Data Unit) 

• Radio handset 

• PA microphone 

• Emergency alarm switch 

• Inside and outside public address speakers 

iii. Confirm whether to use J1708 or other protocol for 
communications. 

iv. Complete programming and software development to 
support required RCU functionality. 

v. Test prototype on a bench 

vi. Field test prototype. Test procedures shall be approved by 
the Contract Administrator. 

vii. Manufacture production units. 

viii. Conduct functional, performance, EMI, RFI and 
environmental testing. 

(d) The Contractor shall integrate the RCU with the DDU. 

(e) The DDU shall be designed to migrate from LIM to FIM 
integration without hardware changes or software upgrade. 

(f) Implementation shall be per the requirements of Section 6.II- 
11.1.2.3. 

6.8.4 Community Transit Integration 

(a) The DDU shall include applications to control the following 
devices on Community Transit vehicles (DR 103.07): 

i. Transit signal priority (TSP). 

ii. Destination sign. 
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iii. GFI Farebox (per section 6.8.2). 

(b) Log-on data shall be entered into the DDU either manually or via a 
driver smart card. The driver will enter the starting trip number 
manually. 

(c) The DDU shall contain a trip data file, and shall check the starting 
trip number against the file. 

(d) If the starting trip number is valid, the DDU shall initialize other 
on-board devices with log-on and starting trip number data. 

(e) If the trip number is invalid, the driver shall be prompted for a 
corrected trip number. 

(f) The DDU shall include functionality to display the next trip 
number based on the trip data file. 

(g) The driver shall be able to select the next trip number, and the 
DDU shall transfer updated trip data to other on-board devices 
upon selection. 

(h) The DDU shall include functionality for the driver to manually 
override the trip number. 

Community Transit has developed an initial trip data file format as part of 

a pilot program as illustrated in Figure 6.III-6.1. It is estimated that the file 

size for approximately 3,000 rows of data is less than 250 Kbytes. The trip 

data file is subject to revision. 

EXHIBIT 6.111-6.1 

PRELIMINARY CT TRIP DATA FILE FORMAT 


Field Number 

Field Length 

Abbrev. 

Length 

Contents 

1 

2 

1 

Owner / Operator 

2 

10 

6 

Effective date 

3 

1 

1 

Days of operation 

4 

8 

1 

Schedule (Weekday, Saturday, 
Sunday) 

5 

3 

3 

Route 

6 

4 

4 

Run 

7 

5 

5 

Trip 

8 

5 

4 

Start of trip (hh:mm) 

9 

5 

1 

Direction of travel 

10 

1 

1 

Fareset 

11 

20 

20 

Unused (to include TSP or 
other data as needed) 


64 47 
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6.8.5 Application Certification 

(a) The Contractor shall provide a process and facilities for certifying 

new applications created on the DDU (DR 103.08) including: 

i. Contractor Developed DDU applications. 

ii. Agency Developed DDU applications. 

(b) Contractor Developed Applications: 

i. The Contractor shall provide processes and facilities for the 
Contractor to certify that any new application does not 
impact other DDU applications or functionality. 

ii. The Contractor shall certify that any new application does 
not impact other DDU applications or functionality. 

(c) Agency Developed Applications: 

i. The Contractor shall provide processes and facilities to 
certify that a new application developed by or on the behalf 
of the Agencies, does not impact RFCS functionality. 

ii. The Contractor shall provide processes and facilities to 
certify that a new application developed by or on the behalf 
of the Agencies, does not impact other (non-RFCS) DDU 
functionality. 

iii. The Contractor shall provide processes and tools for an 
Agency to test and certify that a new application does not 
impact other (non-RFCS) DDU applications. 

(d) Any additional applications shall be certified prior to release in the 

RFCS. 
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6.111- 7 Wireless Data On/Off Loading System (WDOLS) 

6.111- 7.1 Subsystem Description 

The Contractor shall provide a Wireless Data On/Off Loading System (WDOLS) (DR 
104) as the primary method for transferring data to-and-from the OBFTP or the VLU 
to the designated DACS. It is intended that the WDOLS shall be used to transmit 
data from other sources in addition to the FTP. Also, the WDOLS may be used to 
transfer data from FTPs in remote locations where installing a hard wire 
communications link is the less cost effective solution, e.g. stand-alone FTPs located 
on docks in the WSF environment or platforms in the Sound Transit environment, or 
portable FTPs equipped with a wireless client adapter. The proposed technology shall 
be subject to the review and approval of the Contract Administrator. 

In order to support on-board integration in the bus environment, the WDOLS shall be 
a stand-alone unit connected initially to the OBFTP, and reconfigurable such that it 
can be connected in the future to a VLU. High speed (> 1 Mbps) data throughput is 
required in order to support future data on/off load requirements that will extend 
beyond the RFCS data. 

6.111- 7.2 Functional Requirements 

(a) The WDOLS shall automatically initiate the data exchange when a bus or 
other FTP equipped with WDOLS communications capabilities (DR 104.01) 
enters the range of operation, and shall save the data on the designated DACS 
without manual intervention. 

(b) WDOLS equipment at transit bases or other fixed locations (DR 104.02) shall 
be able to communicate with all WDOLS equipped buses, regardless of 
agency. 

(c) Vehicles shall not be required to stop during the data exchange. 

i. The Contractor shall indicate the maximum vehicle speed to permit 
successful data exchange. 

ii. The vehicle speed limit shall be subject to Contract Administrator 
approval prior to implementation. 

(d) At a minimum, the WDOLS shall be used for the following: 

i. Uploading of transaction data captured at the FTP 

ii. Downloading of files such as: 

- Software configuration files 

- FTP initialization 

- Fare tables 
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- Blocked card list 

- Automatic revalue list, if used 

- Other operational parameter tables 

6.111- 7.3 Performance Requirements - WDOLS 

The data transmission speed shall be sufficient to on- and off-load on-board 

transaction data from the entire fleet or designated remotely located FTPs, at a 

minimum on a daily basis. 

(a) The WDOLS data transfer process shall be transparent to current operations 
and shall not require operational modifications. 

(b) The WDOLS shall have a minimum reliability of 30,000 MOHBF. 

(c) The WDOLS shall be able to operate at a range of at least 1000 feet between 
the vehicles and external antenna units. 

(d) The data exchange rate shall be a minimum of 1 megabit per second either for 
a single channel device, or an aggregate of 1 megabit per second for a multi¬ 
channel, simultaneous communications device. 

(e) The data exchange shall not be affected by other Radio Frequency (RF) 
sources or transmissions. 

(f) The WDOLS shall conform to the IEEE 802.lib communications standard or 
Contract Administrator approved equivalent. 

(g) The WDOLS shall include features to support future upgrade to emerging 
IEEE 802. IX standards. 

(h) The WDOLS shall be compatible with existing Agency Cisco Aironet 350 
equipment, and shall not interfere with other 802.1 lb data transfer systems. 

6.111- 7.4 Physical Requirements - WDOLS 

(a) In keeping with a modular, open architecture, the WDOLS shall be packaged 
separately, and not bundled with the FTP or DDU. 

(b) The enclosure materials shall be high strength polycarbonate, cast aluminum, 
stainless steel or equivalent subject to the review and approval of the Contract 
Administrator. 

(c) Enclosure shall be vandal resistant, flame retardant and resistant to common 
solvents and cleaning materials. 

(d) The WDOLS shall be sealed to prevent any degradation in operation due to 
the accumulation of dust, salt, mud, detergents, solvents, or moisture. 
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(e) Any outdoor mounted equipment shall be rated for operation in an exposed 
environment. 

6.111- 7.5 Electrical Requirements - WDOLS 

7.5.1 Vehicle Mounted Equipment 

The electrical requirements specified in Section 6.III-4.5 shall apply to all 
vehicle mounted WDOLS equipment. 

7.5.2 Base or Terminal Mounted Equipment 

The electrical requirements specified in Section 6.Ill-1.6 shall apply to all 
base or terminal mounted WDOLS equipment. 

6.111- 7.6 Data Exchange Requirements - WDOLS 

(a) The Contractor shall provide a high-speed serial communications device that 
meets the performance requirements in 6.III-7.3. In the initial, limited 
integration mode, the WDOLS shall be connected directly to the DDU. In 
the future, full integration mode, the WDOLS shall be disconnected from the 
DDU and connected to the VLU. 

(b) Communications between the WDOLS and DDU/VLU shall be by high speed 
(1Mbps or greater) serial communications. 

(c) The WDOLS shall include data integrity features such as, but not limited to, a 
check to ensure that the data to be downloaded has been captured by the FTP 
and a check to ensure that no duplicate downloads or uploads of data occur. 

(d) In the event of a failed data exchange attempt, the system shall sound an alarm 
at the DDU and the DAC, and log the event in the FTP and the DAC. 

(e) Immediately following the failed data exchange event, the DAC shall notify 
the clearinghouse of the event. 

(f) The WDOLS shall also provide anti-collision such that multiple vehicles can 
be parked in the same area without loss or corruption of data. 

(g) The WDOLS shall be capable of handling data from multiple on-board 
sources, such as the APC system, AVL system, electronic farebox, and 
various engine/vehicle monitoring systems. 

(h) The Base WDOLS shall be capable of sorting multiple data types into 
appropriately labeled files that can be managed with standard data 
management software. 
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(i) The contractor shall propose troubleshooting tools that allow agency staff to 
identify and fix data exchange problems occurring in the WDOLS. 

(j) The Contractor shall provide a method, subject to Contract Administrator 
approval, of managing the data exchange to ensure that the appropriate data is 
exchanged at the appropriate location and time (DR 104.03). 

(k) The WDOLS shall include security protections (DR 104.04) over and above 
Wired Equivalency Protections to guard against: 

i. Unauthorized access to RFCS data transferred via the WDOLS. 

ii. Unauthorized access to Agency networks through the wireless 
system. 

(l) The WDOLS communications approach and security provisions (DR 104.04) 
shall be subject to approval by each Agency’s designated network security 
group or manager. 

(m) The WDOLS security provisions shall conform to Agency policies or 
specifications for IEEE 802.11 based wireless technology. Policies and/or 
specifications shall be provided to the Contractor at Conceptual Design 
Review. 

(n) The WDOLS shall be designed to migrate from LIM to FIM, where the VLU 
or other means will be provided for management of data transferred to or from 
the vehicle. 

6.111-7.7 Installation Requirements - WDOLS 

7.7.1 Vehicle Mounted Equipment 

(a) Any WDOLS related equipment on-board any vehicle shall meet 
the requirements in Section 6.III-4.7. 

(b) The antenna location(s) for each agency shall be subject to 
approval by the respective agencies. 

(c) Any exterior mounted equipment shall be sealed to prevent leakage 
of rain or bus washer fluids through the life of the installation. 

7.7.2 Operating Base Mounted Equipment 

(a) The antenna shall be mounted in or near a location approved by the 
Contract Administrator. 

(b) The Contractor shall finalize the locations of any externally 
mounted antennas with the Contract Administrator during the 
design review process (DR 42). 

(c) The Contractor shall mount all WDOLS related equipment and 
shall make all power and communications connections. 
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6.MI-8 Portable Fare Transaction Processor (PFTP) 

6.MI-8.1 Subsystem Description - Portable FTP 

The Contractor shall provide portable FTPs for Agencies that have a need for a 
portable card reading and transaction processing device. 

The Portable FTP (DR 105) shall be a handheld, ruggedized unit operated by Agency 
personnel to process RFCS transactions in a mobile or portable environment. The 
PFTP will be powered by a rechargeable battery that can be recharged by placing the 
unit in a cradle or by a 12VDC adapter cable for in-vehicle use. 

The PFTP shall be supplied in two configurations: 

1. As a limited function, verifier only PFTP (DR 105.01) for Sound Transit proof 
of payment fare inspection. The unit shall be light, have low power 
consumption, and be able to conduct fare verification with minimal operation 
by the fare inspector. 

2. A full-function PFTP (DR 105.02) for agencies such as WSF and Kitsap 
Transit, and potentially for paratransit and vanpool applications. 

The Portable FTP (PFTP) shall, at a minimum, consist of the modules listed in 
Figure III-8.1. 


Figure 111-8.1 

PFTP CONFIGURATION SUMMARY 


Modules 

Portable 

FTP 

Central Processing Unit 

X 

Contactless Card Interface 

X 

Customer Display/Indicator 

X 

Charger/Cradle 

X 

Communications Interface(s) 

X 

Receipt Printer 

X (WSF Only) 


“X” denotes module required by Contract 


6.111-8.2 Functional Requirements - Portable FTP 

The following functional requirements supplement those stated in Section 6.III-3.2. 

(a) Log-on from Agency personnel shall occur via a log-on smart card or through 
a built-in PFTP keypad. 

(b) For Washington State Ferries, the operator shall be able to select a destination 
and associated fare basis through the portable FTP keypad. 
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(c) Except as noted in (e), the PFTP shall require no interaction other than the tag 
of a card to process an entire transaction. 

(d) The verifier-only PFTP shall record inspection counts by fare category, fare 
type, operator ID, and time segment. 

(e) The PFTP shall allow the operator to override a default fare transaction (e.g. to 
pay for multiple fares from a single card, or to pay a fare other than the 
default). 

(f) The full function PFTP shall perform all functions of the verifier, plus, 

Agency personnel shall be able to: 

i. Determine card balance, number of stored rides on the card, or the 
existence of a pass. 

ii. Provide historical information to the Cardholder by scrolling 
through the transaction history of the last ten transactions stored on 
the card. 

(g) PFTPs for WSF applications shall include a receipt printer. 

6.111-8.3 Physical Requirements - Portable FTP 

8.3.1 Dimensions and Layout 

A sample mockup of each PFTP configuration and its display message sets 

shall be demonstrated at time of PDR. (DR 105.01 and 105.02) 

8.3.2 Structural Features 

(a) The PFTP shall be to be light weight and constructed of materials 
suitable for transit and ferry operations. 

(b) The PFTP shall have a simple built-in keypad to allow operation of 
the device. 

(c) The enclosure shall be corrosion resistant and finished to resist 
abrasion and scratching. 

(d) The unit must be sealed and ruggedized to operate in an outdoor 
marine environment. 

(e) Color and type of finish shall be such that it minimizes reflections, 
cracking and peeling and shall be approved by the Contract 
Administrator during the preliminary design review. 

8.3.3 Carry Case 

(a) The Contractor shall supply a carry case with the PFTP. 
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(b) The carry case shall be of durable construction and materials. 

(c) The carry case shall be designed to be carried on a belt. 

6.111-8.4 Electrical Requirements - Portable FTP 
8.4.1 Rechargeable Battery 



(a) 

The unit shall be equipped with a commercially available 
rechargeable battery, easily replaced in the field. 


(b) 

The battery cover shall be removable without tools and secure 
under normal use. 


(c) 

Rechargeable battery life shall be at least 8 hours under normal 
anticipated operating conditions. 

8.4.2 

PFTP Cradle 


The contractor shall provide a cradle style battery charger for the PFTP. 
The battery charger shall provide a regulated charge that maximizes 
battery life and charges PFTP batteries, at minimum, within one shift. 

8.4.3 Vehicle Charger 

The Contractor shall provide a charger suitable for mounting in a 
Paratransit or Vanpool vehicle with a standard automotive 12VDC 
cigarette lighter connection. 

6.111-8.5 Data Exchange Requirements - Portable FTP 

Data exchange requirements described in Section 6.III-3.6.1(a) are replaced by the 
following: 

(a) The verifier-only PFTP shall communicate with the DACS through a serial 
interface to the PFTP cradle. Subject to communications availability, the 
PFTP shall be able to share the same DACS as the Stand Alone FTP’s 
installed at Sound Transit rail platforms. 

(b) The full function PFTP shall include the following communications ports, 
configurable by application: 

i. A serial communications port for direct connection or connection 
through a cradle. 

ii. A standard telephone modem port. 

iii. A PCMCIA or other industry standard slot for connection of an 
802.11 client adapter, CDPD modem, or other wireless 
communications device. 
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(c) The full function PFTP shall be supplied with the 802.11 client adapter, 

CDPD modem, or other wireless communications device as required (DR 
104.05). 

(d) All communications shall be automatically initiated and completed. 

6.111- 8.6 Additional Security Requirements - Portable FTP 

The Agent or authorized operator shall be required to enter a PIN to activate the PFTP 
and select the required route or service the PFTP is used on. 

(a) PFTP shall generate a record of the sign on/off. 

(b) The sign on/off log shall be transferred to the clearinghouse central system 
daily. 

6.111- 8.7 Environmental Requirements - PFTP 

Environmental requirements as listed in Figure III-3.2 are modified for the PFTP as 
follows: 

(a) Temperature range: +32°F to +110°F operating. 

(b) Humidity: 0-80% relative humidity, non-condensing. 
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6.111- 9 Stand-Alone Fare Transaction Processor 

6.111- 9. 1 Subsystem Description - Stand-Alone FTP 

Stand-Alone FTPs (SAFTP) (DR 106) shall be ruggedized devices installed at Sound 

Transit Stations, and WSF toll booths and ferry docks, and shall be designed for 

pedestal or wall mounting. Two SAFTP configurations shall be supplied: 

1. An SAFTP equipped with zone/destination buttons for Sound Transit (DR 
106.01). Passengers will select the number of zones of travel prior to presenting 
the fare card for payment. 

2. An SAFTP designed for integration as a peripheral to a new Point of Sale (POS) 
system being developed by Washington State Ferries (DR 106.02). This SAFTP 
shall not include zone/destination buttons, but shall include an interface for future 
integration with the WSF Revenue Collection System (RCS) as a fare card 
payment processing device. 

At a minimum, the SAFTP shall consist of the modules listed in Figure III-9.1. 

Figure 111-9.1 

FTP CONFIGURATION SUMMARY 


Modules 

Stand-Alone 

FTP 

* Central Processing Unit 

X 

* Contactless Card Interface 

X 

* Customer Display/Indicator 

X 

Power Supply 

X 

* Communications with DAC and WSF 
revenue system 

X 

Pedestal/wall mount 

X 

Selection Buttons 

X (ST Only) 


“X” denotes module required by Contract 
* Module described in Section 6.111-3 


6.111-9.2 Functional Requirements - Stand-Alone FTP 

The following functional requirements supplement those stated in Section 6.III-3.2. 

(a) Log-on from Agency personnel shall occur via a log-on smart card, through a 
command issued through the DACS (to activate all FTPs at a station), or 
through a command issued from WSF’s point of sale system. 

(b) Zone selection buttons (Sound Transit only) shall allow a customer to select a 
destination zone. The SAFTP shall calculate the fare based on the origin and 
destination zones or stations. 
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(c) The SAFTP (Sound Transit configuration) shall be supplied with up to 10 
zone selection buttons. The final number of zone selection buttons shall be 
determined at PDR (CDRL 2) 

(d) SAFTPs supplied for WSF shall be able to conduct fare transactions as 
follows: 

i. Automatically with no toll booth seller interaction when a card is 
presented and a default fare deducted or pass recorded. 

ii. Through manual fare determination from WSF revenue collection 
(point of sale) system. In this case, the fare will be computed by 
the WSF revenue collection system, with the SAFTP acting as a 
payment acceptance peripheral. Valid pass products shall be 
recognized and applied to the cost of the fare. The remaining fare 
shall be deducted from stored value. 

6.111- 9.3 Performance Requirements - Stand-Alone FTP 

The minimum throughput rate for SAFTPs shall be 45 transactions per minute. 

6.111- 9.4 Physical Requirements - Stand-Alone FTP 

9.4.1 Dimensions and Layout 

A sample mockup of each SAFTP configuration and its mounting shall be 

demonstrated at time of PDR for each mounting location. (DR 106.01 and 

106.02) 

9.4.2 Structural Features 

(a) The SAFTP pedestal shall be constructed of 14 gauge stainless 
steel. 

(b) The wall mount shall be designed for outdoor installation at an 
unattended site, and shall include protection against removal or 
vandalism 

(c) The structural design shall be such that a force of 250 pounds 
applied in a horizontal plane at the topmost point of the SAFTP in 
any of the four mutual sides shall not result in the dislodging, 
bending, or buckling of the SAFTP and/or pedestal or wall mount. 

9.4.3 Keypad (zone selection buttons) 

The keypad/zone selection buttons shall meet the following requirements: 

(a) All keys or buttons shall have a minimum life of 10 million 
actuations. 
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(b) The keypad shall be designed to be water and liquid resistant. 

6.111- 9.5 Data Exchange Requirements - Stand Alone FTP 

(a) SAFTPs shall include a communications module for connecting to a DAC and 
the capabilities to be connected to a PC through a standard port. 

(b) The Contractor shall provide the software for a PC that allows the use of a PC 
keyboard to operate the SAFTP and PC monitor to display the card data. 

(c) SAFTPs supplied for WSF shall include a standard serial interface, designed 
for future connection to WSF’s new point of sale system. The Contractor 
shall provide an Interface Control Document (DR 106.02) fully describing this 
interface. 

(d) SAFTPs and associated DACs installed at Sound Transit rail stations shall 
communicate through Sound Transit’s existing TVM communications 
network. 

6.111- 9.6 Installation Requirements - Stand-Alone FTP 

(a) SAFTPs shall be designed to be installed freestanding on a pedestal or wall 
mounted. 

(b) The Contractor shall provide the Contract Administrator and affected Agency 
with bolt pattern mounting requirements, foundation designs, and 
electrical/communications construction and connection details. 

(c) The Contractor shall provide one (1) set of anchor bolts and all mounting 
hardware, including mounting or pedestal base if required, for each standalone 
SAFTP provided under this contract. 

(d) The Contractor shall be responsible for mounting the SAFTPs with bolts or 
other means to a concrete surface. Each unit shall be properly leveled, 
accommodating station platform slopes of up to 2% traverse and 2.4% 
longitudinal, prior to being permanently installed. 

(e) Removal of SAFTPs shall be possible without damage to concrete or 
attachment devices. The attachment devices shall not be exposed to the 
public after the equipment is installed. 

(f) Conduit, and power and communications cables leading from the power and 
communications sources to the junction box shall be installed by the Agency. 
Connections from the junction box to the SAFTP shall be the responsibility of 
the Contractor. 

(g) The Contractor shall install the SAFTPs over the junction boxes, providing 
bottom entry of power and communication lines such that no wiring or cabling 
is exposed outside the SAFTP cabinet or base, and the Contractor shall make 
final connections (plug-in) to power and communications. 
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6.111- 10 Integration with Sound T ransit TVMs 

6.111- 10.1 Subsystem Description -TVM Integration 

For its Sounder Commuter Rail service, Sound Transit has implemented new ticket 

vending machines (Scheidt and Bachmann model FA 2000/TS [ touch screen]) with 

the capability of being retrofitted with RFCS smart card equipment. These machines 

will also be deployed in the future on Sound Transit’s new light rail line. 

Work under this section includes: 

(a) Retrofitting Sound Transit TVMs with RFCS smart card read/write equipment 
to allow customers to revalue their card at any Sound Transit TVM location 
(DR 107). 

(b) Integrating the RFCS smart card read/write equipment with the credit/debit 
card and cash acceptance functions of the TVM (DR 107.01). 

(c) Integrating RFCS communications with the existing communications from the 
TVMs to the Sound Transit Central Data Collection System (CDCS - DR 
107.02). 

(d) Coordinating with Sound Transit and the TVM vendor (Scheidt and 
Bachmann) to make necessary changes to TVM hardware, software and 
communications (including the customer interface) to support RFCS card 
revalue and inquiry functions. 

6.111- 10.2 Functional Requirements - TVM Integration 

10.2.1 Basic Operation 

(a) All communications between the Card Interface Module and fare 
card shall be via the contactless interface. 

(b) The customer interface shall guide the customer through the steps 
necessary to conduct and complete an RFCS transaction. 

(c) The sequence of customer actions required to complete each 
transaction shall be designed to be as efficient and customer 
friendly as possible. 

(d) The Contractor shall provide the Contract Administrator with 
scripts and screens that define all possible transaction sequences. 

(e) The sequence of actions and timing, the layout and wording of the 
Customer Display prompts are subject to Contract Administrator 
approval (DR 107.03). 
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(f) Final approval will be provided after the Beta Test implementation 
is completed. 

(g) English shall be the language used. 

10.2.1.1 Transaction Selection 

The customer shall be able to choose: 

(a) Transaction type, such as add value or card value/history inquiry. 

(b) Method of payment. 

(c) Desired Agency, when more than one Agency applicable. 

(d) Whether to proceed without a receipt, regardless if a receipt is 
unavailable. 

(e) If a customer presents a fare card without first selecting a 
transaction type, the Display shall default to an inquiry response 
screen. 

i. Withdrawal of the card without any further action shall 
cause the unit to revert to standby for the next transaction. 

ii. Selecting a transaction after card presentation shall 
interrupt the balance inquiry and proceed to next logical 
step in executing the selected transaction. 

10.2.1.2 Card Balances Inquiry 

The response to a “Balance Inquiry” shall display the following 
information: 

(a) Stored value balance on the card. 

(b) Active passes on the card, by Agency. 

10.2.1.3 Stored Value Load 

(a) The display shall show the beginning balance. 

(b) As the customer inserts cash or conducts electronic payment 
transaction, the value displayed shall be increased as cash is 
inserted, or if a credit or ATM card is used as payment, the ending 
balance shall change on approval of the authorization request. 

(c) A load shall be executed after pressing a “load” or “OK” button. 
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(d) When the transaction is completed and the value has been 
transferred to the fare card, the display shall show the ending 
balance. 

(e) If the patron cancels the transaction before any value has been 
added to the card, a refund of the total amount deposited into the 
device shall be returned. 

10.2.1.4 Pass Load 

(a) For pass transactions, the customer shall select the Agency and 
desired fare type. 

(b) The device shall read the reduced fare privileges encoded on the 
card, and automatically determine whether a discount is available 
for the requested type of fare at the relevant Agency (e.g. youth 
monthly pass). 

(c) The device shall display the fare type and value and the customer 
shall select the method of payment. 

(d) The device shall allow a customer to use cash, credit, debit or 
RFCS smart card stored value for pass purchase. 

10.2.1.5 Cash Transactions 

(a) The display shall decrement the value shown as funds are added. 

(b) As soon as the amount paid is equal to or exceeds the fare value, 
the purchase shall be encoded onto the card and, if the option is 
implemented, change shall be returned automatically. 

10.2.1.6 Credit, Debit and ATM Card Transactions 

(a) Customers shall be prompted for a PIN, if applicable; the 
transaction shall be authorized and, if successful, the fare card shall 
be encoded. 

(b) A receipt in accordance with the requirements of Regulation E or 
the gateway bank shall be printed. 

10.2.2 Operating Modes 

The RFCS customer interface shall indicate the operating mode of the 

Sound Transit TVM which may include: 

(a) Normal operating mode 

(b) Limited service modes such as: 
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10.2.3 


10.2.4 


10.2.5 


i. Credit, debit or ATM Card only - both coin and bill 
acceptance are inoperable. 

ii. Cash only - card acceptance is inoperable. 

iii. Bills only - coin acceptance is inoperable. 

iv. Exact change only - No change returned. 

v. Receipt unavailable - when the printer is inoperable. 

Data Capture 

At a minimum, the following RFCS data shall be captured and 
communicated: 

(a) Transaction support messages - such as card payment 
authorization message flows. 

(b) Detailed transaction data - related to the distribution services 
provided at that device since the last poll period, unless this 
information is captured in real time. 

Customer Interface Integration 

RFCS equipment shall be fully integrated with the existing customer 
interface including: 

(a) The customer display. 

(b) Touchscreen or primary keypad. 

(c) Numeric/PIN keypad (model IVI Encrypt 300). 

(d) Voice annunciator and ADA provisions. 

Card Interface Module 

(a) The Contractor shall provide, install and integrate an RFCS card 
interface module. 

(b) It shall be possible to restrict use of credit, debit and ATM cards 
for payment of selected transaction types, and to restrict card 
payments to minimum transaction values. 

(c) These parameters shall be adjustable according to individual 
Agency policies. 

(d) Fare cards shall be revalued using the card interface module. 

(e) The fare card interface shall use contactless technology. 
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(f) The Contractor shall provide features for maintaining data integrity 
and completing the transaction for a contactless interface. 

10.2.6 Printing Integration 

(a) RFCS equipment shall be integrated with the TVM printer. 

(b) The data to be printed, and the formats in which it will be printed, 
shall be software configurable. 

10.2.7 Currency Acceptance Equipment Integration 

(a) The RFCS equipment shall be integrated with currency acceptance 
equipment to allow cash payment for smart card revaluing. 

(b) The RFCS equipment shall record all cash payments attributable to 
card revaluing for subsequent revenue reconciliation. 

6.111- 10.3 Performance Requirements - TVM Integration 

(a) The card reader shall have a reliability of at least 50,000 mean transactions 
between failures on a reader processing at least 10,000 transactions per 
month. 

6.111- 10.4 Physical Requirements - TVM Integration 

(a) The Card Interface Module shall be installed in the space provided in and 
behind the front panel of the Sound Transit TVMs. 

(b) All customer interface equipment shall be installed in the front panel. 

(c) A mockup of the customer interface shall be provided at time of PDR. (DR 
107.03) 

(d) Major subassemblies shall have a permanently attached label inscribed with a 
unique serial number and part number prominently located on the 
subassembly. 

(e) All subassemblies shall be modular and easily replaceable. 

6.111- 10.5 Electrical Requirements - TVM Integration 

(a) RFCS equipment shall be fully integrated with the electrical system of the 
Sound Transit TVMs. 

(b) Contractor shall upgrade the electrical system as needed to support RFCS 
equipment integration. 

(c) Contractor shall verify that all UL requirements have been met (DR 107.04). 
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6.111-10.6 Environmental Requirements - TVM Integration 

RFCS equipment shall be designed to operate outdoors without protection in the 
environmental conditions provided in Figure IE-10.1. 


Figure 111-10.1 


OPERA1 

riNG ENVIRONMENT 


RFCS Equipment 

Temperature Range: 

+14°F to +99°F, Ambient 

Humidity: 

5% -100% RH 

Shock: 

Up to 5g horizontal 

Vibration: 

Same as section 

EMI: 

Same as section 

Other (dust, grit, rain and 
saltwater protection): 

• Maximum 3 inches of rain in 24 hours 

• Maximum 14 inches snowfall in 24 hours 

• Wind (70 MPH gusts) 

• IP55 rating. 


6.MI-10.7 Data Exchange Requirements - TVM Integration 

(a) RFCS equipment shall communicate to the clearinghouse system through the 
existing TVM communications network and Central Data Collection System. 
The existing network includes twisted pair and TCP/IP Ethernet (fiber and 
ISDN) communications to the CDCS. 

(b) The Contractor shall provide information on proposed data transfer method 
and protocols (DR 107.02). 

(c) Under normal operations, all data transmission shall be initiated 
automatically. 

6.MI-10.8 Installation Requirements - TVM Integration 

(a) The Contractor shall provide the Contract Administrator with a detailed 
installation and mounting requirements, including electrical and 
communications connection requirements (DR 107.04). 

(b) The Contractor shall be responsible for coordinating with the TVM vendor to 
integrate RFCS equipment in the Sound Transit TVMs. 

(c) The Contractor shall identify requirements for any required TVM software or 
hardware modifications. 
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6.111-10.9 Testing Requirements and Procedures - TVM Integration 

(a) A minimum of 10,000 transactions shall be conducted. 

(b) Transactions shall be divided evenly among all possible card purchase and 
load transactions of which the device is capable. 

(c) The transactions shall also employ all possible payment combinations for a 
device. 

(d) The stored value amounts, stored pass and stored ride types and amounts, and 
fare amounts shall be representative of those expected to be employed in the 
RFCS. 

(e) Detailed information regarding the transaction types, values, and payment 
methods to be used in the cycling test shall be included in the Detailed Test 
Procedures and subject to Contract Administrator approval. 
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6.111- 11 Customer Service Terminal (CST) 

6.MI-11.1 Subsystem Description - CST 

The CST (DR 108) shall provide the capabilities necessary for supporting RFCS 

through the Agency’s customer service offices and for mail and phone inquiries. The 

Customer Service Terminal (CST) shall at a minimum provide the following 

customer service capabilities: 

(a) Initialize and issue all types of fare cards. 

(b) Encode personal data onto fare card and record it in the RFCS database. 

(c) Create PIN numbers for fare cards (card linking). 

(d) Process, at a minimum, payment by cash; credit, debit and ATM cards, 
electronic vouchers, checks, requisitions and purchase orders. Revalue fare 
cards with fare value from any Agency. 

(e) Issue refunds and replace fare cards. 

(f) Show remaining value and pass status of card. 

(g) List the last ten fare card transactions. 

(h) Unlock locked-out fare cards. 

(i) Provide a transaction history on each fare card by accessing the clearinghouse 
database, and ability to print duplicate receipts. 

(j) Print receipt for each transaction or inquiry of remaining value. 

(k) Enroll customers in automatic revalue program. 

(l) Support the sales of non-RFCS products. 

6.111- 11.2 Functional Requirements - CST 

(a) The CST shall provide a means of quickly selecting “express transaction” 
types for the most common types of card values loaded. For fares dependent 
upon origin/destination, the default origin shall be the zone in which the CST 
is installed. However, CSTs shall be capable of selling rides for any 
origin/destination pair. 

(b) The CST shall be able to read and encode on the fare card any value up to the 
maximum limit, load any pass or type of ride for any Agency. 
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(c) The Agency personnel shall be able to initiate the type of transaction by 
selecting the type of value to be loaded for a selected Agency, and origin- 
destination or zones if applicable. 

(d) Agency personnel shall be able to cancel a transaction at any point during the 
purchasing process prior to the initiation of the transfer of value to fare card. 

(e) The CST shall prompt Agency personnel to select the payment type. 

(f) A transaction receipt may be printed at the CST upon request for any type of 
payment. CSTs for WSF shall print receipts for every transaction by default. 

(g) Upon the completion of the transaction selection, the CST shall calculate and 
display the amount due for the selected card value loaded on the operator 
display as well as the external customer card interface unit display. 

(h) The CST shall be able to reverse the value that has been loaded on to fare card 
and provide an audit trail of who reversed it, including time date and terminal 
ID. 

(i) At the end of a sales day, the CST shall provide a daily summary report 
indicating total sales, revenue collected, passes sold, amounts of refunds 
issued and the number of refunds. 

(j) The CST shall support telephone, Internet and mail order services. 

i. All telephone, Internet and mail orders filled shall be tracked on a 
daily basis. 

ii. The daily orders received and orders filled shall be transferred to the 
clearinghouse at least once per day per Agency. 

(k) The CST shall provide provisions for entering customer information including 
name address, phone number and ID number. 

i. The CST shall have functionality to generate customer numbers. 

ii. The CST shall have functionality to utili z e Agency-specified 
customer numbers. 

iii. The CST shall have the capability to track transactions by customer 
number, transaction numbers, or pass serial numbers. 

iv. The CST shall allow Agency personnel to override the standard pass 
prices, and track and report each override event. 

v. All CSTs, revalue and information devices/systems shall reference the 
same customer identification information record, to avoid duplication 
of records for a specific customer. 

(l) The CST shall record payment method or methods for each sales transaction. 
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(m) The CST shall be capable of operating commercial off-the-shelf software such 
as word processing and spreadsheet programs concurrent with CST functions. 

(n) CST peripherals shall be modular. 

(o) The Agencies shall have the option of procuring: 

i. A fully configured CST designed for over the counter service. 

ii. The core CPU and peripherals (keyboard, mouse and display), with 
additional peripherals (e.g. receipt printer, cash drawer, customer 
display, etc.) as desired by an Agency. The modularized version 
will be used for telephone, mail or other customer service functions 
where the full range of peripherals is not required. 

(p) The CST shall provide a report identifying inventory quantities on hand, 
quantities sold, and quantities added during the day. 

11.2.1 Cash Sales 

(a) The CST shall recognize cash as the default payment method. 

(b) The CST operator shall enter the amount received into the CST 
using the keyboard (the default value, obtained by pressing enter, 
shall be the amount due from the customer for the current 
transaction) and the CST shall encode the fare card. 

(c) In the case of overpayment, the CST shall calculate the change due 
to the customer, display the corresponding amount on the CST 
operator interface screen. 

(d) Cash change shall be provided by the operator via the CST cash 
drawer. 

11.2.2 Check, Purchase Order, or Money Order Sales 

(a) Upon receipt of a money order, purchase order (PO) or check for 
payment, the operator shall either scan the payment through the 
electronic check reader or manually enter the payment number into 
the CST using the keyboard. 

(b) The CST shall provide the following features when processing 
checks and POs: 

i. The CST shall prompt Agency personnel to enter current 
ID, such as drivers license and expiration date. 

ii. The CST shall have the ability to endorse checks and POs 
electronically listing the deposit information on the back of 
the payment, at the time the sale is made. 
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iii. The system shall have the ability to create a bad check file. 

(c) The check number shall be verified against the “bad check” and 
“accepted corporate check/purchase order” files resident in the 
CST. 

(d) For POs or other billing accounts, the CST shall record as a 
minimum: 

i. Company or organization 

ii. Billing address 

iii. Payor contact 

iv. Payor reference number (alphanumeric) 

v. Agency reference number (alphanumeric) 

vi. Notes 

vii. Special handling instructions 

viii. Ship-to address 

ix. Payor telephone number 

(e) Upon local verification of the check/PO at the CST, the CST shall 
send a message to the clearinghouse requesting check transaction 
authorization. 

(f) Such check transactions shall be processed in a manner similar to 
electronic payment transactions. Upon receipt of authorization, 
the CST shall notify the Customer Service Representative (CSR) of 
the check/PO authorization number and transfer value to the fare 
card. 

(g) Bad check and accepted corporate check/PO files shall be updated 
at the clearinghouse and downloaded on a daily basis to the CSTs. 

(h) Check transaction processing shall be conducted in accordance 
with the requirements of the authorizing financial 
institution/network. 

11.2.3 Telephone, Mail and Internet Fulfillment and Customer Service 

(a) The CST shall include functionality to provide telephone, mail and 
Internet Customer Service and Support in a “card not present” 
environment. 

(b) The CST shall include functionality to provide Institutional 
Program customer service in a “card not present” environment. 
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(c) The CST shall generate local card fulfillment orders for Internet 
requests processed through the RFCS Internet Website operated by 
the Contractor on behalf of the Agencies. 

(d) Internet website orders shall be routed to an Agency or Agencies as 
defined by the Contract Administrator. 

(e) The CST shall include functionality to create packing slips and 
mailing labels. Print size and font type shall meet United States 
Postal Service (USPS) standards. 

11.2.4 Electronic Payment (Credit/Debit/ATM Card) Transactions 

(a) The customer shall perform the following steps using an external 
customer card interface unit: 

i. Swipe the card to be used for payment 

ii. Select the type of electronic payment, i.e., credit, debit, or 
ATM card 

iii. Enter the corresponding account PIN number and press 
“OK” (debit transactions only) 

iv. Press “OK” to accept the amount to be charged to the 
corresponding account 

(b) The CST shall immediately receive the account information read 
from the card and the CST operator shall forward the transaction 
authorization request to the clearinghouse by depressing a hot key 
on the keyboard. 

(c) The remainder of the transaction shall be processed in a manner 
similar to that of electronic payment transactions at a TVM, with 
the exception that a duplicate transaction receipt with a signature 
line shall be automatically issued by the CST for all credit card 
transactions. 

(d) The signed receipt shall be retained in the CST cash drawer for 
transaction clearing purposes. 

(e) The CST shall contain provisions for the reversal of a credit/debit 
transaction when the transaction is canceled prior to ticket issuance 
or card encoding. 

(f) The processing of all credit and debit transactions shall conform to 
the requirements of ISO 8583. 


Contract 229944 


6.111-89 


April 29, 2003 




Customer Service Terminal 


Division III 


11.2.5 Fare Card Inventory Management 

(a) When a new fare card is issued and not initialized, the CST shall 
capture the serial number of the fare card for the clearinghouse. 

(b) The CST shall automatically track the card inventory of the 
Agency against the clearinghouse card inventory management file 
as fare cards are sold and initialized. 

11.2.6 Customer Service Agent Sign-On/Off 

(a) When an Agent signs on, the following procedure shall be 
followed after turning the CST on with a key. The Contractor shall 
provide to Program Manager five (5) sets of all CST keys a 
minimum of 60 days prior to the delivery of the first CST. 

(b) Agent’s encoded smart card (Access Card) shall be scanned. 

(c) The following data shall be read from the Agent’s Access Card 

- Agent’s ID number plus encrypted PIN. 

- Agency code. 

- Expiration date of card. 

(d) This shall be followed by the Agent keying in their PIN. The CST 
shall compare the encrypted PIN against the PIN keyed in and the 
CST shall only be operable when the two numbers match. 

(e) The CST shall be set up to automatically record the operator’s sign 
on/sign off PIN and the date/time. The Agent’s encoded card shall 
also be used to sign off. Turning off the key shall disable the CST 
but not remove the Agent’s data. If the first Agent has not signed 
off, the sign-on of a second Agent shall cause an automatic sign-off 
for the first operator without loss of any data. 

(f) The Agent shall be able to key in the working cash fund that is 
available at the start of their shift and to have the CST keep a 
running balance throughout the shift by accounting for cash 
received for any cash sales. 

11.2.7 CST Systems Administration Mode 

Through commands entered using the Agent interface such as the 

keyboard or touch-screen, authorized maintenance and/or revenue service 

personnel shall be able to place the CST into Systems Administration 

Mode. 
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(a) The CST shall have a maintenance and systems administration 
mode function. 

(b) When in Systems Administration Mode, the customer interface 
display shall read “Out-of-Service” and the operator interface shall 
be used to enter commands, perform queries, and receive 
information from the machine on both the monitor screen and on 
audit. 

(c) The CST shall not be capable of loading value onto a smart card 
when in the maintenance mode. 

(d) The CST shall return from the Systems Administration Mode to 
revenue service after servicing. 

(e) The presentation of menu selections to facilitate 
maintenance/revenue service actions at the CST shall be subject to 
Program Manager approval. 

11.2.8 CST Training Mode 

Through commands entered using the Agent interface such as the 

keyboard or touch-screen, authorized Agency personnel shall be able to 

place the CST into Training Mode. 

(a) In Training Mode, the CST shall simulate normal operation 
including actual display messages 

(b) The CST shall not be capable of loading value onto a smart card 
when in training mode. 

(c) A record from the time the CST entered Training Mode to the time 
returned to normal operation shall be created and transferred to the 
clearinghouse central system during the next scheduled data off 
load cycle. 

11.2.9 Non-RFCS Sales 

(a) The CST shall have functionality to process, record and report the 
sales of non-RFCS products. 

(b) The CST shall have the ability to track the inventory of used, 
unused, sold, and on-hand non-RFCS products in the system by 
using barcode or manually entered serial numbers. 

(c) The CST shall provide local inventory and revenue reporting of the 
sale of non-RFCS products. 


Contract 229944 


6.111-91 


April 29, 2003 




Customer Service Terminal 


Division III 


(d) The CST shall provide a combined report of all revenue collected 
and payment methods used to support single deposit. Revenue 
reports shall distinguish between RFCS and non-RFCS product 
sales, amounts and payment methods. 

6.111-11.3 Performance Requirements - CST 

11.3.1 Overall Reliability 

(a) The following reliability rates, Mean Transactions Between Failure 
(MTBF), shall apply for a high transaction volume environment: 
10,000 MTBF. 

(b) The reliability shall be 7,500 Mean Operating Hours Between 
Failure (MOHBF) in a low transaction volume environment. 

(c) High and Low Volume Transaction environments are defined in 
Section 6.III-1.5.1 (a) and (b). 

(d) Any component or assembly within a CST that fails more than two 
(2) times per month shall be replaced with a new component or 
assembly. 

i. If the new component or assembly experiences the same 
failure rate, the Contractor shall be responsible to initiate an 
investigation to determine the cause. 

ii. Alternatively, failures shall average no more than two (2) 
failures per device type every 90 days for the total 
population for each type of CST in revenue service. 


11.3.2 Availability 

Availability shall be measured at a minimum for the following: 

(a) The CST shall be available to conduct a transaction 99.73% [c c 
(second sigma)] during operating hours. 

(b) Credit or debit card authorization shall be available as specified in 
Section 6.HI-1.5.2, “Availability.” 

(c) CSTs shall be available to transmit data upon request to the 
clearinghouse 99.73% [a a (second sigma)] during the scheduled 
time periods for these activities (refer to Section 6.Ill-1.5.2 
“Availability”). 

(d) Contractor shall provide a detailed plan that describes the 
methodology of capturing and processing the data to be used to 
measure availability (CDRL 39). 
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11.3.3 Individual Components 

(a) The card reader shall have a reliability of at least 50,000 mean 
transactions between failures on a reader processing at least 
10,000 transactions per month. 

(b) A thermal printer MTBF shall exceed two million characters and 
the life of the print head shall exceed 50 million characters. 

(c) For dot matrix printers, there shall be no noticeable degradation in 
print quality for at least 250,000 lines of twenty (20) characters per 
line or six (6) months, which ever comes first. 

11.3.4 Accuracy 

(a) The electronic payments functions shall have an accuracy rate of 
99.73% (o c sigma). 

Accuracy for all types of electronic payments is defined as the 
mean ratio of the transactions value recorded by the device as 
evidenced by the transactional data recorded to the actual 
transaction records received and processed by the clearinghouse. 

(b) The cash transaction functions shall have an accuracy rate of 
99.5%. 

Accuracy for the cash processing functionality is defined as the 
mean ratio of the moneys recorded as evidenced by the audit 
receipts produced by the device to the actual moneys in the bill and 
coin vaults as counted. Cash reconciliation differences attributable 
to beginning inventory shortages or loading errors shall be 
excluded. Differences attributable to counting errors shall also be 
excluded. Reconciliation differences shall be reported by relevant 
device within 24 hours. 

6.MI-11.4 Physical Requirements - CST 

(a) The full-function CST shall contain the modules listed in Figure El-11.1. 

(b) Agencies shall have the option of procuring CSTs with any combination of 
peripherals for mail, telephone or other applications that may not require all 
peripherals. 

(c) Agencies shall have the option of procuring additional peripherals as 
illustrated in Figure El-11.2 
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Figure 111-11.1 
CST MODULE SUMMARY 


Module 

Reference 

CST CPU (DR 108.01) 

X 

Magnetic Card Reader-encoder (DR 

108.02) 

X 

PIN pad (DR 108.03) 

X 

Agent Display (DR 108.04) 

X 

Customer Display (DR 108.05) 

X 

Card Reader/Writer (DR 108.06) 

X 

Keypad/board (DR 108.07) 

X 

Printer-Receipt (DR 108.08) 

X 

Cash drawer (DR 108.09) 

X 

Data communications (DR 108.12) 

X 

Secure Access Module (SAM) (DR 

108.12) 

X 


“X” denotes module required by Contract 


Figure ill-11.2 

CST - ADDITIONAL MODULES 


Module 

Reference 

Photo ID Equipment (DR 108.10) 

X 

Card Dispensing Module (DR 108.11) 

X 


11.4.1 Customer Service Terminal 

The Customer Service terminal shall consist of: 

(a) CPU, based on the latest generation of Intel or Motorola microprocessor or 
approved equivalent and shall be configured with sufficient memory, data 
storage, and appropriate communications to meet the functional requirements 
defined for the terminal. Unless otherwise required for the provision of drive 
bays or interface cards, the CPU shall be supplied in a mini-tower 
configuration. If a larger housing is required to accommodate additional drive 
bays or interface cards, the CPU shall be supplied in a tower configuration. 

(b) Full function keyboard or touch screen interface. 

(c) Minimum 17 inch standard PC active matrix LCD monitor. The monitor shall 
be readable in all ambient light conditions, including both day and night. The 
display shall be subject to the review and approval of the Contract 
Administrator (DR 108.04). Due to space constraints at customer service 
offices, some Agencies may require 15 inch LCD monitors in lieu of 17 inch 
monitors. This will be determined at Conceptual Design Review (CDRL 1). 
The CST shall be designed to operate with either a 15 inch or 17 inch 
monitor. 

(d) Default selections on the key board or touch screen shall be provided to speed 
up the transaction process for commonly used transactions. 
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(e) Receipt printer. 

(f) Locked cash drawer. 

(g) A customer display to provide the transactional information to the customer. 

(h) The CST interface shall be subject to Contract Administrator review and 
approval (DR 108.04). 

11.4.2 Customer Interface Unit 

The customer interface unit shall consist of the following: 

(a) Customer data entry/PIN pad connected to the CST via a flexible 
cable. 

(b) The pad shall be a DES/UKPT encrypting numeric keypad for PIN 
entry. 

(c) EMV compliant magnetic stripe card reader. 

(d) Privacy hood or shield to protect the privacy of PIN code entry. 

(e) Display to prompt the customer and to indicate the amounts being 
charged to their credit or debit cards. The display shall indicate that 
PIN entries are being made with * but shall not record the 
characters being entered. 

11.4.3 Cash Drawer 

The CST shall provide a uniquely keyed, lockable cash drawer attached to 

or detached from the CST unit. 

(a) The cash drawer shall be designed and constructed to be pry-proof 
to prevent unauthorized entry when closed and locked. 

(b) If a separate device from the CST, the cash drawer shall withstand 
a drop on any comer or side from a height of 2.5 feet onto a 
concrete floor when containing a full compliment of bills and 
coins. 

(c) The drop incident shall not cause the cash drawer to open and shall 
leave the drawer operational. 

(d) The drawer shall contain a removable subdivided tray for currency, 
coin, checks and other documents received by the operator. 

i. The tray shall have the capacity to separately store a 
minimum of 80 bills of each of 4 US currency 
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denominations and a minimum of 60 coins of each of 5 US 
coin denominations (including SBAs, quarters, dimes, 
nickels, and pennies) in compartments sufficiently sized for 
these items. 

ii. The tray shall also contain two compartments of 4 inches 
by 6 inches and a minimum of 1 inch deep to accept paper 
documents. 

11.4.4 Receipt Printer 

The CST shall include a Receipt Printer as an integral part of the CST or 
as a stand-alone device that interfaces with the CST through a standard 
communications port. 

(a) The receipt printer shall include a roll-type receipt paper feed a 
thermal printer. 

(b) Receipt information shall be software programmable. 

(c) Each Receipt Printer shall be configured to print duplicate receipts 
with signature lines for credit card transactions. 

(d) Printed characters shall be in black print, smudge resistant when 
handled immediately by the operator or customer. 

(e) Receipt printing for any type of transaction shall take no longer 
than 4 seconds. 

11.4.5 Photo Identification System 

The contractor shall provide the capabilities to print a photo on to special 
fare cards categories in support of the RRFP or other photo/ID programs. 

(a) The photo identification (ID) system shall consist of the following 
components: 

i. Digital camera. 

ii. Application software. 

iii. Card printer. 

iv. Card lamination unit, if required. 

(b) The photo ID system shall process and print the image on to the 
fare card at a maximum of five (5) minutes. 

(c) Once the printing process is completed the image shall be smudge 
proof and permanent for the life of the fare card. The image may 
be laminated with a clear plastic sheathing as protection. 
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(d) The photo ID system shall be able to operate on the CST hardware 
platform. 

(e) A single photo ID system shall be accessible from multiple CSTs 
through an Agency’s network. 

(f) The Agencies have identified the need for the following quantities 


of the photo ID system: 

i. Community Transit 1 

ii. Everett Transit 1 

iii. King County Metro 3 

iv. Kitsap Transit 1 

v. Pierce Transit 4 

vi. Sound Transit 1 

vii. Washington State Ferries 0 

11.4.6 Card Dispenser 


(a) The card dispenser shall be capable of independently distributing 
two (2) different card products including the fare card and 
disposable fare card. 

(b) The card dispenser shall be housed in a secure, lockable housing. 

(c) A means shall be provided for keeping the card stock unexposed 
and secure at all times outside of card stock replacement actions. 

(d) Each card dispenser magazine shall be capable of holding a 
minimum 300 fare cards. 

(e) The cards shall be dispensed in an automatic fashion upon the 
receipt of payment at the CST for a smart card sales transaction. 

(f) Dispensing time shall be one (1) second or less. 

(g) The following Agencies have indicated interest in procuring card 
dispensers: Community Transit, Washington State Ferries and 
Everett Transit. 

6.111-11.5 Electrical Requirements - CST 

In the event of a power interruption, a rechargeable dry or sealed gel cell battery 
source (or UPS) shall provide auxiliary power to the CST for a minimum of 10 
minutes of full operation. And at the end of the 10 minutes, complete the transaction 
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in progress and allow for orderly shutdown of the CST, including transmitting all 
audit data and alarm conditions to the clearinghouse. 

6.111-11.6 Environmental Requirements - CST 

CST shall be designed to operate in the environmental conditions provided in 
Figure HI-11.3. 

Figure 111-11.3 

OPERATING ENVIRONMENT 



Customer Service Terminal 

Temperature Range: 

Climate controlled office environment and WSF toll 
booths 

Humidity: 

Climate controlled office environment and WSF toll 
booths 

Shock: 

Minimum 20g non-operating, 2.5g operating. 

EMI: 

Applicable FCC requirements 

Other (dust, grit, rain/water 
protection): 

Climate controlled office environment 


6.111- 11.7 Data Exchange Requirements - CST 

(a) CST event and transaction data shall be transferred to/from the clearinghouse 
via a Contractor provided communications network. 

(b) Data back-up features shall be included to maintain the integrity of all data 
stored in the CST in the event of system or component failure. 

6.MI-11.8 Installation Requirements - CST 

(a) The Contractor shall install and setup all elements of the CSTs in the 
designated customer service offices. 

(b) To the extent practical, the equipment shall be secured to prevent theft or 
damage. 

(c) The Contractor shall make all connections to power and communications, all 
connections between CST elements, and route all cables neatly and out of the 
way. 

6.111- 11.9 Additional Security Requirements - CST 

11.9.1 Alarms 

(a) The CST shall be provided with an alarm that notifies the 
clearinghouse when an unauthorized entry occurs. 
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(b) Both the alarm and method of activation/deactivation shall be 
subject to Program Manager approval. 

11.9.2 Keys 

The Contractor shall provide to the Contract Administrator five (5) sets of 
all CST keys a minimum of 60 days prior to the delivery of the first CST. 

6.111-11.10 Agency Specific Requirements 

11.10.1 King County Metro POS System Integration 

The Contractor shall integrate current POS application software into the 
RFCS CST (DR 108.14). 

11.10.1.1 King County Metro Hardware and Operating System 

The King County Metro POS system is a client/server application. The 
server operating system is Redhat Linux (7.1 kernel). Desktops are Intel 
Pentium class 1.2 GHz personal computers with 256 MB RAM, with a 
Windows 2000 operating system running SecureCRT (a Linux terminal 
emulator). 

11.10.1.2 POS Application Software 

King County operates a Counterpoint software application, produced by 
Synchronies, and written in MicroFocus Cobol. The database engine is 
Pervasive.SQL. 

All POS transactions are processed and reported through Counterpoint. 
This includes an Internet pass sales system with on-line order processing, 
payment and account management. Sales information from the Internet 
pass sales system is batch processed and integrated in Counterpoint with 
other POS data. 

The Contractor shall assess the feasibility of integration of the RFCS 
application with King County’s POS and on-line Internet pass sales system 
versus replacement of the existing POS system with RFCS CST system. 

11.10.1.3 Reporting 

At the end of the sales day, the RFCS CST shall provide a combined daily 
summary report indicating total sales, revalue funds collected, passes and 
other fare media sold, amounts of refunds issues, and the number of 
refunds from both the RFCS CST and King County POS system. 
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11.10.2 Portable CST Application (Option) 

The Contractor shall provide a version of the CST application software for 
installation on an Agency-supplied laptop computer. This computer will 
be used to collect customer data in the field for subsequent issuance of a 
fare card with or without Regional Reduced Fare Permit information. 

The portable CST application shall provide the following functionality: 

(a) Capture of customer fare card and Regional Reduced Fare Permit 
information in the field in an off-line mode, and creation of a new 
customer record. 

(b) Transfer of digital photographs from an Agency supplied digital 
camera in the field, and association of the photographs with the 
corresponding customer records. 

(c) Transfer of captured data and images to the RFCS clearinghouse 
upon connection of the laptop computer to the RFCS network at 
the Agency facilities. 

(d) Ability to issue cards using the customer service terminal and 
photo identification system installed at an Agency. 
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6.111- 12 Data Collection System 

6.MI-12.1 Subsystem Description - Data Collection System 

The data collection system (DR 109) shall consist of distributed data acquisition 
computers (DACs) throughout the region. DACs collect the data from On-Board, 
Portable and Stand-alone FTPs or other designated RFCS equipment for transfer to 
the clearinghouse and provide the relevant Agency with duplicate data files of the 
data files transferred to the clearinghouse. 

6.111- 12.2 Functional Requirements - Data Collection System 

(a) The application program shall use an MS Windows standard graphical 
interface. 

(b) The use of proprietary hardware and/or software shall be subject to Contract 
Administrator review and approval. 

(c) The DAC shall operate without manual intervention. 

(d) All data up and down loading to the clearinghouse or to On-Board, Portable 
and Stand-alone FTPs shall be fully automated. 

(e) The DAC clock shall be synchronized with the clearinghouse clock prior to 
beginning a data transfer. 

(f) The Agency DAC shall allow access to a rolling 90 day database of complete 
trip transaction records for the Agency through the clearinghouse. 

(g) The DACS shall interface to the clearinghouse through the Back Office Client 
Computer per Section 6.Ill-13. 

6.111- 12.3 Performance Requirements - Data Collection System 

(a) The Contractor shall provide a detailed plan that describes the methodology of 
capturing and processing the data to be used to measure availability (DR 
109.01). 

(b) This plan is subject to Contract Administrator review and approval. 

(c) The Contractor may add equipment or increase system redundancy levels in 
order to meet or exceed availability requirements. 

(d) System availability shall be measured at a minimum for the following: 

i. DAC shall be available to transmit data to the clearinghouse 99.73% 
and to on- and off-load the data from the FTPs 99.73% during the 
scheduled time periods for these activities. 
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ii. The combined system elements such as FTP, WDOLS, DAC, and 

clearinghouse system shall be available 99.73% of the time when they 
are required for system operations. 

6.111-12.4 Physical Requirements - Data Collection System 

12.4.1 Data Acquisition Computer 

(a) The DACS shall consist of standard PC components with 
minimum requirements as follows: 


Component 

Requirements 

CPU 

Intel Pentium 4 or Xeon, operating at >1.5 
GHz. Tower configuration 

Keyboard 

Extended keyboard 

Network Interface Card 

10/100 Mb/s Ethernet NIC 

Mouse 

Scrolling 

RAM 

>512 Mb 

Monitor 

>17” viewable active matrix LCD 

Hard Drive 

>40Mb, 7200 RPM 

CD ROM 

>48x 

Removable Media 

CD R/W with software to write large data 
files across multiple CD’s 

Operating System 

Windows-based (NT, 2000, XP 

Professional) 


(b) The applications shall be programmed in high order languages such 
as JAVA, Visual Basic, or C++ and distributed objects. 

(c) Industrial enclosures shall be used as required in hostile 
environmental conditions. 

(d) Each DAC shall have sufficient hard disk space to hold a minimum 
seven days of transactions. 

6.111-12.5 Electrical Requirements - Data Collection System 

(a) The requirements specified in Section 6.M-1.5. shall be met. 

(b) In the event of a power interruption, a rechargeable dry or sealed gel cell 
battery source (or UPS) shall provide auxiliary power to the DAC for a 
minimum of 30 minutes of full operation; and shall allow for an orderly 
shutdown of the DAC, including completion of the transmission of all audit 
data and alarm conditions to the clearinghouse. 
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6.111-12.6 Environmental Requirements - Data Collection System 

DAC shall be designed to operate in the environmental conditions provided in 
Figure HI-12.1. 

FIGURE 111-12.1 
OPERATING ENVIRONMENT 



Data Acquisition Computers 

Temperature Range: 

Climate controlled environment 

Humidity: 

Climate controlled environment 

Shock: 

Minimum 20g non-operating, 2.5g operating. 

EMI: 

Applicable FCC requirements 

Other (dust, grit, rain/water 
protection): 

Climate controlled environment 


6.111-12.7 Data Exchange Requirements - Data Collection System 

12.7.1 RFC system Architecture 

(a) The Contractor shall develop a comprehensive RFC system 
Architecture, reflecting the interface requirements shown in 
Figure III-12.2. 

(b) The System Architecture shall include optional or alternative 
elements to be implemented in the future, as defined in this RFP or 
proposed by the Contractor. The Contractor may also propose 
additions to the core system architecture such as the provision of a 
headquarters computer. 

(c) The System Architecture shall be submitted with the design 
documentation and shall be approved by the Contract 
Administrator. 

12.7.2 Data Communications 

(a) The DACS shall communicate with the clearinghouse. 
Asynchronous communication using File Transfer Protocol (FTP) 
over TCP/IP at 56 kbps or greater shall be provided. 

(b) All data packets shall be tagged with DACS header information 
including as a minimum DACS ID, transit base ID, date stamp, and 
time stamp. 
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Figure MI-12.2 

REVALUE DEVICE AND COMPUTER SYSTEMS 
INTERFACE REQUIREMENTS 
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(c) The DACS shall be equipped with required data communications 
interfaces including modem or network cards. 

(d) Under normal operations, all data transmission shall be initiated 
automatically. 

(e) Uploading of data from designated equipment to the DAC shall 
occur on a timed poll basis, at a minimum daily, or when 
equipment memory is at a predetermined threshold level. 

(f) Download of data to designated equipment from the DAC shall 
occur at Agency pre-determined times of-day. TheDAC shall have 
the capability to mirror the FTP displays in real time or allow the 
FTP transaction to be remotely monitored. 

(g) DACs installed at Sound Transit rail stations shall communicate 
through the existing TVM communications network. 

6.111- 12.8 Installation Requirements - Data Collection System 

(a) The Contractor shall install and setup all elements of the DAC in the designated 
Operating Bases and Agency offices. 

(b) Each Agency is responsible to provide a secure location for the equipment to 
prevent theft or damage. 

(c) The Contractor shall make all connections to power and communications, all 
connections between DAC elements, and route all cables neatly and out of the 
way. 

6.111- 12.9 Additional Security Requirements - Data Collection System 

(a) Every access, authorized and unauthorized, to the DAC shall be logged and 
reported. 

(b) Data maintained by the DAC shall be protected from loss, manipulation, and/or 
disclosure through an encryption methodology, such as DES. 
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6.111- 13 Back Office Data Integration 

6.111- 13.1 Subsystem Description 

Back office data integration shall include a client application (DR 110) to provide 
standard revenue and ridership reporting, RFC system reporting. Agency-specific 
reporting, ad-hoc query reporting, and fare table update functionality. The client 
application will provide the primary data interface to the clearinghouse system, and 
will contain functions for the generation of reports and transfer of data to legacy 
systems. The client application will also allow consolidated reports to be generated 
using fare card and non-fare card data transferred both from the clearinghouse system 
and directly from the data acquisition system (non-fare card data recorded by the 
FTPs). 

The client application shall be designed to operate on a standard PC-based 
workstation at each Agency (either provided by the Agency or provided under this 
Contract). Communications to the clearinghouse system shall be via LAN/WAN or 
other means (e.g. asynchronous dial-up). The Agencies are interested in solutions that 
leverage off modem client-server or N-tiered application development technology. 

The Client Application (in conjunction with local server if applicable) shall support 
the following high level business functions: 

1. Revenue Information and Reconciliation - This is the information typically 
needed daily for posting to the Agencies General Ledger application. Some 
Agencies require categorized totals for manual entry to the GL (e.g. 8 - 10 data 
points representing sales by pass type, and realized e-purse revenue by fare type). 
Other agencies require transaction level revenue data. 

2. Ridership Information and Processing - This is information on fare card use, 
provided at the transaction level, or summarized daily, weekly, monthly, quarterly 
or other period, used by each Agency to report ridership characteristics for local 
and regional reporting. 

3. System Performance Reporting - This is information about the performance of 
the RFC system including management information reports such as financial 
management, customer service, inventory systems operation, and system 
status/maintenance reports such as fault tracking, exceptions, and support service 
statistics. 

The client application shall include a data export functionality to export/transfer data 
from the clearinghouse system and DACS to each Agency’s legacy revenue and/or 
ridership systems. This functionality could be implemented via industry standard 
software techniques such as batch-automation, real-time connectivity, or manual data 
entry, depending upon the system integration requirements of each participating 
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Agency. This will allow the Agencies to generate custom reports with their existing 
back-office systems. 

Flexibility and extensibility is also required to allow the creation of new reports, 
modify existing reports, and administer new types of fare tables to support new fare 
policies such as distance based fares. 

6.111-13.2 Functional Requirements 

13.2.1 Back-Office Client Application 

(a) The client application for the back-office system integration is 
designed to be the common data-management solution for all 
participating Agencies. The client application functional 
requirements shall complement the Agency specific integration 
functional requirements. 

(b) The Contractor shall be responsible for providing workstation 
hardware and software for the client application at each Agency. 

(c) The back-office client application shall include capabilities for an 
agency to correct erroneous data or reports, and update 
clearinghouse and other databases and reports automatically. This 
does not include changing revenue data. 

13.2.1.1 Clearinghouse Data Reporting 

The Contractor shall develop reports as specified in 6.HI-13.3, Data 
Exchange and Reporting Requirements. All reports shall be generated by 
the back-office client application. 

13.2.1.2 Agency Specific Fare Table Administration (DR 110.01) 

(a) The back-office client application shall administer and 

electronically transfer fare table data to the clearinghouse. The 
following list of properties is provided as a guideline for the 
Agency’s fare table input, and subsequent transfer to the 
clearinghouse: 

i. Agency I.D. 

ii. Unique Fare ID Reference 

iii. Description String of Fare Type 

iv. Start Date/End Date 

v. Fare Amounts 

vi. Rider Demographic Category fare rules 

vii. Rider Peak/Off-Peak fare rules 
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viii. Rider Frequency-based fare rules 

ix. Rider Day-of-Week fare rules 

x. Rider Holiday fare rules 

xi. Inter-Agency Rider commute fare rules 

(b) The back-office client application shall administer existing fare 
tables, and shall be extensible to administer new local and inter¬ 
system fare tables. 

(c) The back-office client application shall administer a minimum of 
three (3) fare tables: Prior, current and those for the next fare or 
service change. 

(d) The client application shall have read-only access to the fare table 
from the preceding service period. 

(e) The client application shall include functionality to test fare tables 
prior to forwarding to the clearinghouse. 

13.2.1.3 Agency User Administration 

The back-office client application shall provide the following user 
administration functions: 

(a) Add new Agency user 

(b) Update Agency user 

(c) Remove Agency user 

(d) Disable Agency user 

13.2.1.4 Agency Application User-Defined Environment Views 

The back-office client application shall provide the following user defined 
environment views: 

(a) Standard User View - Whereby the user will be only able to view a 
standard Agency operational view of data and application features. 

(b) Standard Power User View - Whereby the user will be able to view 
a standard Agency managerial view of data and application 
features. 

(c) Standard Administrator View - Whereby the user will be able to 
view a standard Agency RFCS back-office integration 
administrative view of data and application features. 
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(d) Customized View - Whereby the user can configure the application 
to show only user-relevant information in which they are permitted 
to interact with based on their security clearance level. 

13.2.1.5 Import/Export Report Data 

The back-office client application shall provide the following data 

import/export functions. All functions shall be available for all report 

categories specified in 13.3: 

(a) Data Files (Import Source / Export Destination) - This option will 
include the ability to specify input or output file format including, 
but not limited to Comma Delimited, User Defined Delimiters, 
Fixed Field Width, and XMF (a tagged data format). 

Note: The XMF export option will support the direct republishing 
of summary information on an Agency Intranet, or the Internet (in 
the case of information open to the public). Specifications and 
additional information on XMF can be obtained from 
http ://w w w. w3. org/xml. 

(b) DSN Resource (Import Source / Export Destination) - This option 
will facilitate the transfer of data from the clearinghouse to 
Agency’s local systems. In this function the user shall be able to 
specify a target Data Source Name (DSN) and table. The system 
shall accept a user-defined compatible DSN (column count, and 
data types) for the destination table. The interfaces for this 
function shall accept user input of any DSN entries configured on 
the workstation via the Windows control panel, or equivalent 
workstation interface. 

(c) Printing (Export Destination) - The user will be able to select from 
a list of printers configured for the client application’s operating 
system. Connection to the printer may either be direct (serial or 
parallel) or via a local area network (FAN). The client application 
should take advantage of Operating System print servers to 
maximize the number of printers compatible with the application. 

13.2.1.6 RFCS Database Connectivity 

(a) The Contractor shall provide connectivity to the clearinghouse 
database that meets all the requirements for access and 
performance described in this document. 

(b) The Contractor shall provide a connection strategy that is 
consistent with modem wide-area computing technology. 
Whenever possible the Contractor shall utilize industry standard 
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technology (connectivity hardware, communications protocols, 
replication technology, etc.). 

(c) The Contractor shall provide failure analysis documentation for the 
proposed connectivity strategy. This document will address 
emergency recovery plan, and emergency (or "off-line") operation 
procedures. 

(d) The system shall notify the Agency system administrator of 
communications failures to the clearinghouse system. 

(e) The client application shall not remove, delete or alter data records 
at the clearinghouse system. 

13.2.1.7 RFCS Database Archive Administration 

This feature allows archiving of data transferred to the client application; it 
does not include archiving or modification of data at the clearinghouse 
system. 

(a) The Contractor shall provide an archive function to provide the 
Agency with off-line or near-line storage of historical 
information. The back-office client application shall provide the 
following database archive functions: 

i. Agency-specific archive. The system shall allow data to be 
archived weekly, monthly, and quarterly (3 months) to the 
target media. The archive scheduling shall be 
programmable by each Agency. 

ii. Inter-Agency Archive Subset. This will archive Inter- 
Agency information to the target media. The Agency may 
wish to keep Agency-specific historical information on-line 
longer than Inter-Agency information. 

(b) Records in an archive set shall be flagged or stamped with the 
current date and time. Incremental archiving shall be provided. 

(c) Each Agency will be responsible for implementing the 
administrative duties of the archival process. The archive function 
shall support industry standard media (tapes, disks, CD's) typical 
for the workstation architecture and operating system. 

13.2.1.8 Inter-Agency Data Sharing Filter Administration 

The back-office client application shall provide the following inter-Agency 
data sharing filter administration functions. These are features of 
convenience, designed to allow the user to display or hide data in a 
specific view. 
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(a) {Display I Hide} All Agency Public records 

(b) {Display I Hide {Specified Agency Public records 

(c) {Display I Hide } Specified Agency Private records 

(d) {Display I Hide } Specified Inter-Agency records 

13.2.1.9 Event Logging 

The back-office client application shall provide the following event 
logging functions. The log entries shall occur automatically, and without 
user intervention: 

(a) Agency Fare Table Administration Events 

(b) Pass Sales Transactions 

(c) Agency User Administration Events 

(d) Batch Scheduled/User Executed Report Generations Events 

(e) Performance metrics for report generation/data sharing events 

(f) Data Import/Export Events 

(g) Database Query Errors 

(h) User Security Events 

(i) Inter-Agency Data Sharing Administration 

(j) Inter-Agency Data Sharing Transactional Events 

(k) Clearinghouse data transactions 

13.2.1.10 Local Fare Card Revenue Control Total Reporting 

The definition of the control total reporting method is a one to one 
aggregate comparison between totals from the DACS set of revenue detail 
records and the totals from the clearinghouse set of revenue detail records 
for a particular Agency business day. The difference between DACS 
revenue total and the clearinghouse revenue total is defined as the control 
total variance. Control totals provide an approximation of fare collection 
revenues owed to an Agency, but are not expected to represent true 
revenue owed once all transactions have been reconciled. 
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(a) The back office client application shall include functionality to 
process and report total reconciled and un-reconciled fare card 
revenue collected at each Agency. 

(b) Reports shall be provided on a daily basis. 

(c) The back office client application shall compare control totals 
received from the DACS with reconciled totals received from the 
clearinghouse on a daily basis. 

(d) The back office client application shall create a variance report and 
report the source of the variance. 

(e) The back office client application shall activate an alarm if a 
control total variance exceeds a user-defined threshold. 

13.2.1.11 Consolidated Fare Card and Non-Fare Card Ridership Reporting 

(a) Some Agencies will collect non-fare card data through the fare 
transaction processors. The back-office client application shall 
include functionality to process and generate consolidated ridership 
reports for all fare card and non-fare card data recorded on the fare 
transaction processors. 

(b) The back office client application shall include functionality to 
correct “double counting” of fares that include a fare card 
underpayment, coupled with a non-fare card “upgrade”. 

13.2.1.12 Ad-Hoc Reporting 

The back-office client application shall include the following ad-hoc 

reporting functions. 

(a) A graphical interface for the creation of the database query. The 
user can choose table(s), field(s), conjunctions, conditionals, and 
output order (ascending or descending). The user can select one or 
two field(s) for "Group-by" to organize the results in a hierarchy 
(e.g. report on annual pass sales per month group-by 'sales- 
location'). 

(b) A query editor that allows the user to create a new query using a 
standard structured language. This same interface may be used to 
edit a query that was built from the graphical query builder. 

(c) A graphical interface for the creation of the report formats. The 
user will be able to define page size, margins, footers, headers, 
page breaks, font size and style, and simple graphical elements. 
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(d) A function to save a report design for future execution, or editing. 

(e) A query batch submission service feature, which would enable the 
Agencies to have query/report results, sent to the submitting 
Agency via standardized digital media (e.g. DAT tapes). This 
service would reduce network bandwidth usage and improve data 
accessibility. 

13.2.1.13 Business Day 

(a) The Contractor shall coordinate the upload and download of data 
based on each Agency’s administrative business day. 

(b) The Contractor shall be able to handle changes to the Agency’s 
administrative business day. This may require coordination with an 
event triggered by the Agency (as opposed to a time table system). 

13.2.2 Functional Requirements (Agency Specific) 

The Contractor shall develop the Agency client application to meet the 
following requirements: 

(a) Provide reports/data for integration into existing Agency reports 
and databases. 

(b) The client application shall be integrated with the following legacy 
systems: 

i. King County Metro, ASCII data file or direct ODBC 
connection to a workstation to be provided by KCM. 

ii. Washington State Ferries, integration with new revenue 
collection system as described in 6.HI-16.7. 

iii. Kitsap Transit, ASCII data file transfer. 

iv. Pierce Transit, Oracle DBMS and Microsoft SQL 
RDBMS. 

v. Community Transit, Oracle DBMS. 

vi. Everett Transit, no legacy system. 

vii. Sound Transit, Central Data Collection System (CDCS - 
under development). 

(c) The Contractor shall coordinate with Agency personnel and other 
contractors supporting legacy systems as listed in Figure IE-13.1. 

(d) The Contractor shall be responsible for developing the client 
application such that it is compatible and integrated with existing 
systems. 
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Figure MI-13.1 

LEGACY SYSTEM SUPPORT CONTRACTORS/PERSONNEL 


Agency 

Contractor 

King County Metro 

KCM staff 

Kitsap Transit 

KT staff 

Pierce Transit 

PT staff 

Community Transit 

CT staff 

Everett Transit 

Solutions for Government (SFG) and 
City staff 

Sound Transit 

To be determined at implementation 

Washington State Ferries 

WSF staff 


13.2.2.1 King County Metro (DR 110.02) 

(a) Daily sales reports shall be provided to the Finance Department for 
automated and/or manual entry to the general ledger or accounts 
receivable system(s). Sales information shall be broken down by 
pass type and by vendor identifier (e.g. Consignment, Group Sales, 
RFCS managed sales). Transaction revenue (from stored value) 
shall be broken down by Peak, Off-Peak, and Special fares (Senior, 
etc.). Files for automated entry shall be provided using ASCII file 
export or ODBC connection. 

(b) Transaction level Ridership data (including driver and vehicle 
assignment information, and all trip data) shall be provided 
through electronic data transfer to the KCM server. This 
requirement could be met by the Import/Export Report 
requirements using either ASCII file export as an intermediate step, 
or direct ODBC transfer if the KCM Transit Distribution Database 
supports this. 

(c) Currently, KCM’s administrative business day is defined as 8 a.m. 
to 5 p.m. KCM maintains a separate “service day” for transit 
operations. 

13.2.2.2 Kitsap Transit (DR 110.03) 

(a) Daily revenue reports from the RFC system shall be provided by 
fare type. These will be manually entered into the existing 
Fundware general ledger system. 

(b) On a daily basis, ridership data from the client application shall 
generate a formatted ASCII data file via the client application data 


Contract 229944 


6.111-114 


April 29, 2003 





Back Office Data Integration 


Division III 


export feature. This data file/ODBC connection data shall be 
imported into an existing Microsoft Excel system. 

(c) At the time this specification was written, a final decision about a 
new accounting system had not been made. The most likely 
product under consideration is “Fundware for NT”. The Contractor 
shall provide functionality to export data to this product 

(d) Currently, KT’s administrative business day is defined as 8 a.m. to 
5 p.m. 

13.2.2.3 Pierce Transit (DR 110.04) 

(a) RFCS revenue data shall be transferred to the existing finance 
system via ODBC type middle-ware, or by transfer command in the 
back office client application. 

(b) Pierce Transit operates a financial system using an Oracle 
RDBMS. 

(c) Currently, PT’s administrative business day is defined as 8 a.m. to 
4:30 a.m. 

13.2.2.4 Community Transit (DR 110.05) 

(a) Community transit is implementing a new ERP system based on 
Oracle financial packages, using Oracle 7.3.n or Oracle 8 as the 
back-end. The client application shall interface with this system via 
ASCII data file transfer in CSV format or direct ODBC connection 
to a workstation provided by CT. 

(a) The Contractor shall provide daily revenue reports broken down by 
fare and pass types. These numbers will be manually entered into 
the GF system. 

(b) Community Transit has contracts with third-party transit providers, 
who are responsible for their own revenue reporting. The back- 
office client application shall report all third party fare card 
revenue, summarized by provider. 

(c) Currently, CT’s business day is defined as 8 a.m. to 5 p.m. 
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13.2.2.5 Everett Transit (DR110.06) 

(a) Daily reports from the RFC system shall be provided summarizing 
sales by fare type. These will be manually entered into the existing 
financial systems. Currently, Everett Transit hosts a legacy 
COBAL financial system called SFG. They also use Microsoft 
Excel to aggregate revenue and ridership data. Everett Transit has 
no current plans to upgrade their existing systems. 

(b) Currently, ET’s administrative business day is defined as 8 a.m. to 

5 p.m. 

13.2.2.6 Sound Transit (DR 110.07) 

Sound Transit (ST) is implementing an Automated Fare Collection system 
that will eventually become integrated with the RFCS. ST’s system will 
collect fare data from ticket vending machines and validators, and transfer 
that data to the Central Data Control System (CDCS). The CDCS will 
provide the ST interface with the client application and clearinghouse 
system. 

Sound Transit will also be installing fare collection (farebox and RFCS 
fare card) equipment on new bus services. 

(a) The RFCS Contractor shall coordinate with the ST Contractor to 
provide the necessary information to integrate the ST system into 
the RFCS. The ST Contractor will be responsible for making any 
necessary modifications to the CDCS to accommodate the upload 
of information from CDCS to the RFCS clearinghouse. 

i. The RFCS Contractor shall provide ST with the application 
software to transfer RFCS transaction data from the CDCS 
to the clearinghouse system. 

ii. The RFCS Contractor shall provide ST with the software 
drivers and RFCS card application for the TVM card 
readers. 

(b) The RFCS Contractor shall provide to ST the transaction data 
format required to complete modifications to CDCS for transaction 
uploads to the clearinghouse. Refer to Appendix B-5 for a 
preliminary list of messages. These messages are subject to change 
as Sound Transit implements its Ticket Vending Machine project. 

(c) Currently, ST’s administrative business day is defined between 

6 a.m. to 12 a.m. 
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13.2.2.7 Washington State Ferries 

Washington State Ferries is implementing a Revenue Collection system 

(RCS) that will be integrated with the RFCS as described in Section 6.IIt- 

16. The RCS will collect smart card fare data through the RFCS, and will 

provide the interface to RFCS subsystems and the clearinghouse. 

(a) The Contractor shall coordinate with WSF and the RCS contractor 
to provide the necessary information to integrate RFCS systems 
with the RCS. 

(b) The Contractor shall provide WSF with the application software to 
transfer RFCS transaction data from the RCS to the clearinghouse. 

(c) Currently WSF’s administrative business day is defined as 8:00 
a.m. to 5:00 p.m. WSF maintains a service day from 4:00 a.m. to 
3:00 a.m. the following calendar day. 

13.2.3 RFCS Client Application Support 

(a) The Contractor shall provide on-site technical services necessary to 
fulfill the functional requirements of each Agency’s back-office 
functions connected with the RFC system. 

(b) The Contractor shall provide scheduled and emergency on-site 
maintenance of the client application. 

6.111-13.3 Data Exchange and Reporting Requirements 

(a) The RFCS shall provide the following minimum data exchange and reporting 
between the clearinghouse and each Agency’s existing revenue and ridership 
systems: 

i. Standard System Performance 

ii. Standard Ridership and Revenue 

iii. Ad-hoc Ridership and Revenue 

iv. Agency-Specific Ridership and Revenue 

(b) All reports shall be generated using a query language and standard query 
engine (to be approved by the Contract Administrator) that provides flexibility 
for future updates, and for creation of new reports. 

(c) Report writer software shall include the ability to generate graphs and charts 
based on criteria and format defined by the user. 

(d) All reports shall be generated with configurable time parameters, including as 
a minimum annual, monthly, weekly, daily and with user defined start-end 
date ranges. 
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13.3.1 


Standard System Performance Reporting 

As a minimum, the RFCS shall generate the following standard system 
reports daily, weekly, monthly, quarterly and annually (DR 110.08): 

(a) Financial management reports, including as a minimum: 

i. Sales reports by end point (devices in the revalue network, 
CSO, FTP, clearinghouse system) 

ii. Sales by payment type 

iii. Failed transaction reports 

iv. Card account activity reports 

v. Daily settlement and reconciliation reports 

vi. Daily financial activity summaries 

vii. Cash management reports, including cash position 

viii. Financial trend analysis 

(b) General management information reports, including as a 
minimum: 

i. System utilization reports 

ii. Card management performance statistics, including card 
failures 

iii. Systems operations reports 

iv. Fraud management reports 

(c) Contractor provided customer service reports, including as a 
minimum: 

i. Call center level of service and performance against quality 
standards 

(d) Institutional program reports, provided to both the Agencies and 
institutions, including as a minimum: 

i. Summary reports on overall program participation, by fare 
media and Agency. 

ii. Ridership statistics by Agency and transit services used. 

iii. Card account transaction history (monthly or other pre¬ 
arranged schedule) 

iv. Billing, receivable and revenue account status 

v. Subsidy status including all redeemed and un-redeemed 
subsidies 
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vi. Vanpool use by institution, by card number (to be reported 
to the vanpool administrator at each Agency) 

vii. Vanpool subsidies (to be reported to the vanpool 
administrator at each Agency) 

(e) Inventory management reports, including as a minimum: 

i. Card procurement and central inventory 

ii. Ordering and inventory at each point in the distribution 
network 

iii. Delivery performance 

iv. Bad stock, returns, and defects 


(f) System maintenance reports (DR 110.09), including as a 
minimum: 

i. System-wide inventory report 

ii. Summary fault tracking report 

iii. Technical support service statistics 

iv. Extended maintenance reports 

v. Daily exception summary report 


13.3.2 Standard Fare Card Ridership and Revenue Reporting 

13.3.2.1 National Transit Database Reporting (DR 110.10) 


(a) The RFCS shall generate unlinked passenger trip reports for each 

Agency. Reports shall contain: 

i. Annual unlinked trip totals. 

ii. Average weekday, Saturday and Sunday unlinked trip 
totals. 

iii. Unlinked trips by mode including motor bus, trolley bus, 
vanpool, rail, and demand responsive services. 

(b) The RFCS shall generate passenger fare reports for each Agency. 

Reports shall contain: 

i. Total passenger fares. 

ii. Fares by fare category, including as a minimum full-fare 
(adult), senior citizen, student, special fares. 

iii. Fares by mode, including as a minimum motor bus, trolley 
bus, vanpool, rail, and demand responsive services. 
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13.3.2.2 Common Ridership and Revenue Reporting (DR 110.11) 

The RFCS shall generate the following ridership and revenue reports for 

each Agency. 

(a) Monthly summary ridership reports, broken down by: 

i. Route. 

ii. Agency or contractor owning coach. 

iii. Service or agency operated under. 

iv. Fare category (per the fare categories of each respective 
Agency), and exceptions or upgrades. 

v. Fare payment type (stored value, each type of pass), value 
of payment. 

vi. Average weekday ridership. 

vii. Average Saturday ridership. 

viii. Average Sunday ridership. 

ix. Unlinked trips. 

x. Linked trips (transfers) within Agency public transportation 
services. 

xi. Linked trips (transfers) to other Agency public 

transportation services. 

(b) Daily ridership reports, broken down by: 

i. Route. 

ii. Agency or contractor owning coach. 

iii. Service or agency operated under. 

iv. Fare category (per the fare categories of each respective 
Agency), and exceptions or upgrades. 

v. Fare payment type (stored value, each type of pass), value 
of payment. 

vi. Unlinked trips. 

vii. Linked trips (transfers) within Agency public transportation 
services. 

viii. Linked trips (transfers) to other Agency public 

transportation services. 

(c) Monthly fare media in use summaries, broken down by: 

i. Stored value or pass type. 


Contract 229944 


6 . 111-120 


April 29, 2003 




Back Office Data Integration 


Division III 


ii. Current month fare cards in use. 

iii. Comparison with previous month 

iv. Average weekly fare cards used on a each Agency’s 
service. 

v. Year to date fare cards used on each Agency’s service. 

vi. Comparison with previous year. 

(d) General daily, weekly, monthly, and year to date revenue reports, 
broken down by: 

i. Agency-specified revenue account. 

ii. Stored value transactions. 

iii. Pass sales/revalues. 

iv. Funds transfers. 

v. Comparison with previous month (monthly only). 

vi. Comparison with previous year. 

(e) Pass sale/revalue summaries, broken down by: 

i. Sale/revalue location identification. 

ii. Pass type. 

iii. Revalue amount. 

iv. Subsidy amount and type. 

v. Payment method (cash, credit, debit, funds transfer, 
purchase order, other). 

(f) Monthly fare underpayment summaries, broken down by: 

i. Fare card identification 

ii. Fare type (stored value, type of pass). 

iii. Route or terminal identification. 

iv. Fareset in effect. 

v. Amount of underpayment. 

vi. Bus operator, seller, or inspector identification. 

(g) General accounting reports, including as a minimum: 

i. Accounts receivable. 

ii. Accounts payable. 

iii. General ledger. 
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iv. Accounting data by Agency specified revenue accounts. 

(h) For pass and stored value transfers between Sound Transit and 
local agencies (Community, Everett, King County Metro, and 
Pierce Transit), daily, weekly, monthly and year to date revenue 
reports broken down by: 

(i) Total value of transfers between Sound Transit and each 
local agency classified by each type of pass, full payment 
by stored value, and payment by pass and stored value 
indicating pass classification used and amount of stored 
value upgrade. 

(ii) Allocation and disbursement of actual revenue collected 
between Sound Transit and each local agency. 

(iii) Comparison with previous month. 

(iv) Comparison with previous year. 

(i) For pass and stored value transfers between local agencies 
(Community Transit, Everett Transit, King County Metro, and 
Pierce Transit), daily, weekly, monthly and year to date revenue 
reports broken down by: 

(i) Total value of transfers between local agencies classified by 
each type of pass, full payment by stored value, and 
payment by pass and stored value indicating pass 
classification used and amount of stored value upgrade. 

(ii) Allocation and disbursement of actual revenue collected 
between local agencies. 

(iii) Comparison with previous month. 

(iv) Comparison with previous year. 

13.3.3 Ad-Hoc Fare Card Ridership and Revenue Reporting 

Through the back office client application, the RFCS shall provide each 

Agency with the ability to prepare ad-hoc reports (DR 110.12) including as 

a minimum: 

(a) Transaction-level reports for user-defined start and end points, 
including as a minimum the following fields or subset thereof 
defined by the user: 

i. Card Number or Identifier 

ii. Institutional Account Number 

iii. Vehicle ID 

iv. Route ID 
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v. Run ID (bus and rail) 

vi. Trip ID (bus and rail) 

vii. FTP ID, with bus or terminal cross-reference 

viii. Bus operator, WSF seller, or ST fare inspector ID 

ix. Date of transaction 

x. Time of transaction 

xi. Amount or value of transaction and pass type 

xii. Valid fare payment, upgrade or underpayment 

xiii. Linked or unlinked trip 

xiv. Agency transferring from (if applicable) 

xv. Route or terminal transferring from (if applicable) 

xvi. Run transferring from (if applicable) 

(b) Statistical and research reports using user-defined criteria. 
Examples include: 

i. Usage characteristics for user-defined customer market 

segments, potentially broken down by type of fare payment 
used (stored value or type of pass), geographic area or 
route, period of travel, and/or frequency of travel. 

ii. Pass type used versus fareset. 

iii. Card revalues by geographic area or revalue location. 

(c) Functionality for generating reports on a regional basis, including 
linked and unlinked trips for any combination of Agencies in the 
region. Provisions shall be included to limit user access to 
Agency-specific data per permissions and policies of each 
individual Agency. 

13.3.4 Agency Specific Fare Card Ridership and Revenue Reporting 

In addition to the standard and ad-hoc reports, the Contractor shall provide 
the following Agency specific reports (DR 110.13). Sample report formats 
are contained in Appendix B. Except where noted, the Contractor may 
provide alternative report formats, subject to approval by the affected 
Agencies. 

13.3.4.1 King County Metro 

The Contractor shall provide data exchange for the preparation of the 
following KCM-specific reports. Samples of King County reports are 
provided in Appendix B-2. 
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(a) Revenue Passenger Trips Reports (Monthly) 

Reports for two fare category types: Stored Value (monetary 
valuation) and period pass. The Contractor shall provide data 
exchange support data below as required by this report: 

i. Actual Weekly/Monthly Revenue 

ii. Actual Current Year-to-date Revenue 

(b) Current Year vs. Previous Year: Comparison of the number of 
passes in use (Monthly) 

The Contractor shall provide monthly and year-to-date totals for all 
fare card stored value and pass transactions. 

This monthly report shall be broken-down by fare category types, 
and shall show the following specific views of rider data relative to 
each transaction typc:_ 

i. Current Month’s total passes in use 

ii. Current Month’s Year-to-date total passes in use 

(c) Daily Passenger Rides (Monthly) 

The Contractor shall provide daily totals for all fare card stored 
value and pass transactions. This monthly report shall be broken- 
down by day of month and day of week, and shall show the total 
number of rides per day for each category of transaction. 

(d) Fare Media in Use and Sales Report (Monthly) 

The Contractor shall provide daily totals for all fare card stored 
value and pass transactions. 

This monthly report is a series of reports designed to illustrate the 
outstanding fare media (pass) that are in use and sold for the 
month. The Comparison of Passes in Use (Appendix B-2) 
illustrate the need to support the data exchange requirement of the 
different types of pass functions that may be need to be supported 
by the RFC system. The Contractor shall provide report 
information in the same format. 

13.3.4.2 Kitsap Transit 

The Contractor shall provide data exchange capabilities to enable Kitsap 
Transit to generate the following reports: 
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(a) Passenger Totals (Daily) 

This is a sample of driver shift report. This report deals with rider 
"head count' over the span of the driver’s shift. This level of 
information shall be maintained by the RFCS. 

(b) Ridership Recap (Monthly) 

The Contractor shall provide data exchange support for the number 
of riders year-to-date and broken down by weekdays, Saturday, or 
Sunday routes. This report illustrates requirements for year-to-date 
rider counts (Appendix B-3). 

(c) Saturday Service- Routed Service Monthly Performance Report 
(Monthly) 

The Contractor shall provide data exchange support for the number 
of riders by route location and total passengers for the location for 
the specific month. This report illustrates requirements for monthly 
ridership route counts for day-of-week specific routes only. 

(d) Routed Service Monthly Performance Report (Monthly) 

The Contractor shall provide data exchange support for the number 
of riders by route location and total passengers for the location for 
the specific month. This report is the more generalized form of the 
previous report, stated above (Appendix B-3). 

(e) Comparison Report of Routed Service Routes (Monthly) 

The Contractor shall provide data exchange support for the 
ridership information by Route/ by Month, and report and compare 
the previous years information (after the system has been running 
for a year). 

13.3.4.3 Pierce Transit 

The Contractor shall provide data exchange to support the preparation of 
the following reports: 

(a) Revenue and Ridership Reporting (Monthly, Quarterly and Year 
End) 

The Contractor shall provide a comma delimited ASCII file 
compatible with the Average Daily Ridership report described in 
Appendix B-4. The first two (2) pages of E-4 contains a sample 
report that shows how Pierce Transit breaks up bus fleets, and 
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route categories. This is provided for illustrative purposes, but does 
not include the full range of fields that will be required for RFCS 
implementation. 

The Contractor may fulfill this functional requirement by providing 
revised documentation that describes Back-Office Client export 
instructions, and Excel import instructions, or may provide an 
alternative method (subject to Agency approval) that fulfills the 
reporting requirements. 

(b) Wheelchair Lift and Bicycle Report (Daily and Monthly) 

The Wheelchair Lift report shows wheelchair lift utilization by 
fleet type (boardings only). This information is manually counted 
by drivers via the farebox keypad, and reported using an Excel 
spreadsheet. The same method is also being used to track the 
volume of bicycle boardings by route and fleet type. 

The Contractor shall provide similar reports for wheelchair lift and 
bicycle boarding information keypunched into the LTP by the 
driver. 

(c) Average and Peak Reports (Daily and Monthly) 

i. The Contractor shall provide information to support the 
creation of the following charts. Peak ridership is the 
average (over multiple days) of the maximum number of 
passenger boardings in a specified time period. 

- Average Weekday Ridership 

- Average Saturday Ridership 

- Average Sunday Ridership 

- Seattle Express Northbound Peak 

- Seattle Express Southbound Peak 

Examples of these charts have been provided in 
Appendix B-4. 

ii. The Contractor shall provide reports on average and total 
passenger boardings by trip number and route. This may be 
included as part of the Common Ridership and Revenue 
Reports described in 13.3.2.2. 
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(d) Pass Distribution/Reconciliation (Monthly) 

This report contains monthly information by revenue categories, 
and totals by pass, or fare type. The RFCS may cause some pass 
types to be obsolete, and may add new types to the report. An 
example is contained in Appendix B-4. 

(e) Pass/Ticket Sales Information (Monthly) 

This report presents daily sales counts of pass sales. There is one 
edition of this report for every sales outlet. The information on this 
report is summarized in the next report "Pass Distribution/ 
Reconciliation". The example report is an excellent resource for 
Pass Types that the system shall support for integration with Pierce 
Transit. 

(f) Pass Distribution/ Reconciliation (Monthly) 

This report shows totals by pass type by sales outlet. This report 
summarizes the daily information provided in the Pass/Ticket Sales 
report described immediately above. 

13.3.4.4 Community Transit 

The Contractor shall provide data exchange support for the following 
reports: 

(a) Monthly System Performance Report (see example in Appendix 
B-l). 

The report requires the following information totaled by route and 
performance center for weekdays, Saturdays, Sundays: 

i. Number of passenger boarding. 

ii. Payment type (cash purse, period pass, transfer) and 
amount. 

iii. Pass type (CT local, CT commuter, regional employer, U- 
Pass). 

iv. Fare category (senior, youth, disabled). 

v. Number of transfers to/from other transit systems and the 
associated routes. 

vi. Number of internal linking transfers at the route and 
performance center level. 

(b) Provider Reports: 
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This category is required for CT to support their existing business 
practice of multiple service contracts. The Contractor shall provide 
quarterly ridership and revenue summary reports for each 
contracted service provider. 

(c) Financial Reports: 

i. Sales by retail/kiosk location, including the total of each 
category of item sold. 

ii. Interest earnings with a brief description of the 
computation. 

iii. Cash receipts received by invoice number for each specific 
employer. 

iv. Sales by performance center. 

v. Sales by provider (Contractors). 

vi. Summary of cash receipts by category that reconciles with 
the daily total cash receipts. 

13.3.4.5 Everett Transit 

(a) The Contractor shall provide data exchange support for ET’s GL 
interface. 

(b) The Contractor shall obtain a data dictionary from Everett Transit 
and finalize data exchange needs. 

(c) The Contractor shall develop the data interface in mainframe 
interface description language. 

13.3.4.6 Sound Transit 

The Contractor shall provide data exchange for the preparation of reports 
by ST’s CDCS per the data requirements contained in Appendix B-5. 
Additional data exchange and financial reporting requirements for Sound 
Transit, beyond the standard reports, is currently under review. 

13.3.4.7 Washington State Ferries 

The Contractor shall provide data exchange for the preparation of WSF 
reports with content as listed under 6.III-13.3.4.1 (King County Metro). 

13.3.5 Non-Fare Card Transaction Reporting (DR 110.14) 

(a) At the direction of each Agency, the reports listed in Sections 
13.3.2, 13.3.3 and 13.3.4 shall include and consolidate non-fare 
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card data collected through the fare transaction processor and data 
acquisition system. 

(b) Non-fare card data shall be listed as one or more additional fare 
types. As a minimum, a “cash” fare type shall be included. 

6.111- 13.4 General Computing Environment 

The intent of this section is to illustrate general industry guidelines and Agency 

preferences for hardware and operating system software. It is also the intent of this 

section to include, and not limit this application to, a multitude of application 

technology solution types for the Agency Back-office Integration. 

(a) The Contractor shall provide a back-office solution that is compatible with the 
computing environment of each Agency. 

(b) The Contractor shall provide the exact specifications for new systems to be 
integrated with legacy systems to the Agencies and their designates, including 
other Contractors responsible for legacy systems. 

(c) The Contractor shall provide a means for users to manage processes or sub¬ 
processes (threads) of the client application. This requirement may be fulfilled by 
using native operating system utilities to monitor, pause, or terminate lengthy 
processes as needed. 

13.4.1 Back-Office Client Application Computer 

(a) The Back Office Client Application Computer shall meet 
minimum standards as listed in Section 6.HI-12.4.1, and shall be 
approved by the Contract Administrator (DR 110.15): 

(b) Data back-up and redundancy shall be provided to protect against 
data loss. 

6.111- 13.5 Performance Requirements 

13.5.1 Back-Office Client Computer 

(a) Upon database query, print, or any other application function, the 
application shall return control to the user within five (5) seconds 
of initiation. 

(b) All transactions shall be successfully processed. 

13.5.2 Data Transfer and Report Generation Response Time 

(a) Fare Table Updates: Fare table transfer to the clearinghouse system 
shall be completed in less than ten (10) seconds. 


Contract 229944 


6.111-129 


April 29, 2003 




Back Office Data Integration 


Division III 


(b) Standard Reports: Standard reports shall be generated in less than 
ten (10) seconds (this does not include the printer time to complete 
the output). 

(c) Ad-Hoc Reports: Ad-hoc reports shall be completed in less than 
fifteen (15) seconds. (This does not include report design time, the 
report layout "Save" operation, or printer time to complete the 
output). 

"Complete" is defined as - "Full control of the workstation has returned to 
the user". Background processing strategies may be implemented to fulfill 
response time requirements. 

13.5.3 Reliability and Accuracy 

(a) Reporting process: All reports shall perform the correct 
calculations for sub-totals, totals, and summary information (all 
derived information) with 100% accuracy. The underlying standard 
report design (including mathematical formulas) shall be available 
to the Agencies for review. 

(b) Fare table updates: The Back-Office Client shall correctly transfer 
the Fare Table revisions to the clearinghouse system with 100% 
accuracy. 

(c) Transaction recording functions: The Back-Office Client shall 
correctly store information into the clearinghouse database with the 
appropriate field and form level validation. 

6.111-13.6 Installation Requirements 

(a) The client application and all of its supporting hardware and software shall be 
installed by the Contractor. At each Agency's discretion, Agency personnel 
may perform the installation. 

(b) The Contractor shall design and develop a simple to use installation program 
for the client application software. This program should be designed so that 
non-technical staff may install the client application. The instructions for 
installation may include directions for requesting network connections, and 
login accounts from application, or network administrators. 

6.MI-13.7 Additional Security Requirements 

The Contractor shall provide the following additional requirements: 

(a) All direct access to clearinghouse system data shall be read-only, except for 
Fare Table updates. 
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(b) For the client application, the Agencies shall have the ability to assign access 
privileges to their employees for processing of data downloaded from the 
DACS or clearinghouse system to the local RFCS back-office client 
application. Employees shall not be able to modify fare card data to be 
forwarded from the DACS to the clearinghouse system. 

(c) All query operations, audit control logging, and errors on the client application 
shall be logged in a separate ASCII file or database. 

6.111-13.8 Documentation Requirements 

13.8.1 Back-Office Client Application 

The following documentation for the back-office client application shall 
be provided. 

(a) Agency Operations Manual 

(b) System Administration and Installation Manual 

(c) User Manual 

13.8.2 Back-Office Integration (Agency-Specific) 

The following documentation shall be provided describing the integration 
at each Agency: 

(a) System Integration Architecture Diagrams and Documentation 

(b) System Installation Procedures 

(c) System Maintenance Procedures 

(d) System Performance Monitoring Strategy and Procedures 

(e) System Test Plans and Procedures 

(f) Emergency Technical Support Procedures 

(g) Bug-Fix Reporting and Software Service Pack Release Request 
Procedures 
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6.111- 14 Non-Fare Applications (Option) 

6.111- 14.1 Description 

The Agencies have identified the following non-fare application (CDRL 40) to be 
included as an option in the Regional Fare Coordination System. The Contractor shall 
also consider future incorporation of the Non-Fare Application described in Section 

6.m-16.8. 


The Contractor shall include the following Non-Fare Application: 

(a) A Parking Revenue Collection System (PRCS) for Pierce Transit, to be 

installed at the Tacoma Dome Station Parking Garage. Detailed requirements 
for the PRCS will be provided at the time of Option execution. 

6.111- 14.2 General Requirements 

(a) All non-fare applications shall utilize RFCS smart card technology. 

(b) Non-fare applications shall not impact the functionality of the transportation 
application. 

(c) Non-fare applications shall not impact the performance of the transportation 
application. 

(d) Non-fare applications shall be extensible to other sites, other similar 
applications, and other agencies. 

6.111- 14.3 Parking Revenue Collection System 

14.3.1 Functional Requirements 

(a) The Contractor shall provide the following parking revenue 
collection system card configuration options on a single card: 

i. Parking revenue collection system application only. 

ii. Parking revenue collection system application and RFCS 
transportation application. 

(b) The parking revenue collection central equipment shall be 
expandable to include the future addition of other parking 
facilities. 

(c) The parking revenue collection system shall be extensible to other 
Agencies. 
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6.111- 15 System Expansion and Potential Future Applications 

6.111- 15.1 Description 

The following are examples, provided for background information only, of the types 
of future potential RFCS smart card applications that have been identified to date. 
These specific applications will not be evaluated in the Contractor selection process. 
With these types of applications to consider, the Contractor should describe in general 
terms the characteristics of its system architecture, card design and operating policies 
which would allow for additional non-RFCS applications to the RFCS card. The 
system proposed will be evaluated and scored based on its capability to expand and 
incorporate future, additional applications. 

15.1.1 King County Access Identification and Access 

This includes integrating the RFCS card with existing building 
identification and access systems for a number of current and future King 
County building and garage facilities. Estimated card and reader quantities 
and technical information on existing identification and security systems is 
contained in Appendix C. 

15.1.2 Car Sharing Program 

Car sharing, a program to be co-sponsored by King County Metro, the City 
of Seattle, and the University of Washington would provide access to 
automobiles without the costs and hassles of auto ownership. 

Car sharing is similar to typical car rental services; however, vehicles are 
parked within walking distance of home or work and billing is based on an 
hourly rate, rather than a daily rate. Reservations are made by phone or on 
the Internet and fees are based on time and miles driven. There is typically 
an initial refundable deposit to subscribe to the service. All insurance is 
included in the mileage and hourly rates. For more detail on how the 
program works, see the King County Metro website: 

http://transit.metrokc.gov/tops/oto/carshare.html 

King County Metro and Kitsap Transit are also interested in a car sharing 
type program focused on the ferry commuter. Vehicles might be placed 
near ferry terminals that would be available to people who have taken the 
ferry. These vehicles might be part of a HOV commute trip or might be 
available for emergency service when a regular transit service is not 
available. The smart card would be used to access these vehicles and track 
usage. 
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15.1.3 City of Seattle “City Card” 

The City of Seattle is considering the development of a “city card” based 
on European models where citizens have a card to access various city 
services and benefits and pay utility bills, parking tickets, parking meters, 
pet licenses, garbage stickers, etc. as well as link to regional transit 
systems, monorail, car sharing, and guaranteed ride home services. 
Additionally, in return for performing community service Seattle residents 
may get benefits such as purchase of discounted tickets at publicly- 
subsidized facilities l ik e the aquarium and the zoo, discounted purchases at 
stores, credit on City utility bills, et al. The Seattle Smart Card would be 
available only to Seattle residents, providing an attractive transportation 
and civic benefit for people who live in Seattle. 

15.1.4 Transit Oriented Development - Fare Incentives and Secured 
Access 

King County plans to use smart card technology to provide transit pricing 
incentives for residents at Transit Oriented Development (TOD) sites, and 
for secure parking and building access at these sites. In January, 1998, 

King County launched a new TOD program to create opportunities for 
new multi-family housing and related development near bus transit 
facilities in its urban centers. The two (2) primary goals of this program 
are to increase bus ridership and to achieve a greater jobs/housing balance 
in the region by creating communities where public transportation use is 
convenient. 

King County is currently undertaking six (6) pilot projects for this 
program. Downtown Renton and Redmond Overlake are under 
construction, and developer selection/construction is pending on the 
Northgate, Olson-Myers park and ride and the Doces (downtown Seattle) 
sites. A new pedestrian bridge has been constructed just south of King 
Street Station connecting the north Kingdome lot and Pioneer Square to 
existing Metro bus and future Sound Transit commuter-rail and light-rail 
stops. Further development of the north Kingdome lot is expected in the 
future. 

For more information, go to: 

http ://w w w .metrokc. go v/kcdot/alts/tod/index .htm 

6.MI-15.2 King County Identification and Building Access 
15.2.1 Functional Requirements 
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(a) The Contractor shall provide an identification and building access 
system for the following King County building and garage 
facilities: 

i. The Regional Justice Center located in Kent, Washington. 

ii. The King County Correction Facility in 2001/2002. 

iii. Buildings within the General Government building system 
including (at present): the Courthouse, Administration 
Building, Garage, Yesler Building, and remote sites; 
Ryerson Transit Base, Issaquah District Court, Department 
of Youth Services, Alder Complex, and the King County 
Sheriff’s MARR Impound Lot. 

iv. King Street Facility. 

v. The Black River Building located in Kent, Washington. 

Information on the equipment at these facilities is contained in 
Appendix C. 

(b) The Contractor shall supply fare cards compatible with the existing 
identification and building access system. The existing system 
utilizes Motorola Indala AC132 26 bit cards. The total estimated 
number of cards is 20,000. 

(c) In the event the proposed fare card is not compatible with the 
existing systems, the Contractor shall supply the cards, readers and 
all other systems and equipment required for the identification and 
building access system. The total estimated number of readers (not 
including spares) is 400. Equipment information can be obtained 
from the manufacturer’s Internet web sites as listed in Appendix C. 

(d) The identification and building access system shall use site codes 
and card /employee numbers as provided by King County. 

(e) The identification and building access card shall be inter-operable 
across all facilities, subject to individual access permission. 

(f) The Contractor shall provide the following identification and 
building access card configuration options on a single card: 

i. Identification and building access application only. 

ii. Identification and building access application and RFCS 
transportation application. 

(g) The Contractor shall be responsible for integrating new equipment 
and services with existing central monitoring, control, network 
management, and reporting systems. 
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(h) New equipment and services shall be compatible with existing 
communications and electrical supply. 

(i) Cards issued for identification and building access shall be dye 
sublimation compatible with the existing systems. 

15.2.2 Performance Requirements 

(a) New equipment and systems shall not impact the performance of 
existing central monitoring, control, network management and 
reporting systems. 

(b) New equipment and systems shall meet or exceed all current data 
storage and processing performance measures. 

6.111-15.3 Car Sharing Program 

15.3.1 General Requirements 

RFCS cards could be used to perform the following functions of the car 
sharing service: 

15.3.1.1 Access to Vehicles 

The card would act as the subscriber’s ID card. The on-board access 
control system would recognize the user as the correct subscriber and 
allow access into the vehicle. Subscribers gain access to the vehicle by 
holding their card next to an access device located on the front dash of the 
car. 

15.3.1.2 Access to the Lock Box and Ignition Key, or Vehicle Based Security 
System 

The card, in conjunction with a PIN number, would allow access into a 
lock box that may be installed inside the vehicle or located close to the 
vehicle. The vehicle ignition key would be stored inside the lock box. 
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The card, in conjunction with a PIN number, would allow on board 
security ignition system to start vehicle for approved driver. 

15.3.1.3 Record Keeping for Billing 

Card access to the lock box would also act as a record keeping function for 
customer billing. Billing, which is based on mileage and hours used, could 
be handled in two ways. Fees could be deducted from the value stored on 
the card, or fees could be billed to a subscriber’s credit card account. 

15.3.1.4 Reservations by Phone 

Cards would be used for reservations over the phone wherever the phone 
is properly equipped for such use. 

15.3.1.5 Gasoline and Car Wash Purchases by Subscribers 

Gasoline and car washes purchased by the subscribers will be reimbursed 
by the car sharing organization since these costs are included in the 
mileage and hour usage fees. Subscribers would use their card to access 
gasoline and car wash services; however, these expenses would be billed 
to the car sharing organization. 

15.3.1.6 Access to Secured Parking Garages 

The card would allow access to secured parking garages for after hours 
access to vehicles. The access may be through the building security system 
or through an interface unit that translates authorization to the security 
system. 

6.MI-15.4 City of Seattle “City Card” 

15.4.1 General Requirements 

RFCS cards could be used to perform the following “City Card” functions: 

15.4.1.1 Community Service Component 

Volunteer and community work would be rewarded at a set rate (e.g. 

$ 10/hr.) The City would distribute Microsoft Access database compatible 
software to non-profit agencies where the volunteer work was performed. 
The agencies would send the information (by e-mail if the database isn't 
larger than 2 megabytes) with number of hours worked and amount of 
credit earned to the central processing system. Smart card readers and sales 
points would be installed at each Neighborhood Service Center (i.e., a 
storefront office with personnel to conduct City business and address 
citizen inquiries). When citizens use their smart cards at Neighborhood 
Service Centers to pay bills, their smart card would be credited for the 
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volunteer hours. Smart card readers may also be installed at the Zoo, 
Seattle Center, or the Aquarium and with participating merchants to pay 
all or a portion of entrance fees and/or goods and services purchased. 
Funds would be provided to the clearinghouse by the City (raised from 
foundations and private sources, or from fees paid by merchants or banks) 
to subsidize this program. 

15.4.1.2 Linkage with the Regional Fare Coordination System 

The City would coordinate system design and procurement with King 
County and the Regional Fare Coordination contractor to tailor the Seattle 
Card to be compatible. The Seattle Card would have additional functions 
unique to the City, which would be negotiated with the RFC system 
contractor. 

15.4.1.3 Potential Linkage with Merchants and Long Distance Telephone 
Systems 

The New York Chase/Citibank pilot, which enlisted 650 merchants, may 
be a model for this part of the Seattle project. Restaurants, department 
stores, Laundromats, vending machines and taxicabs are potential card 
acceptors. Each business would have a smart card reader. Some might 
even be replenishment stations to add more value to the cards. 

15.4.1.4 Potential Linkage with the Washington State Electronic Benefits 
Transfer System Project 

The State, through the Department of Social and Health Services (DSHS) 
is a member of a seven state consortium developing a magnetic stripe 
Electronic Benefit Transfer (EBT) system through Citibank which will 
begin to go on-line next year. DSHS feels that within five (5) years there 
may be a conversion to smart card technology. At this time, most food 
stores that accept food stamps have debit and credit card reader equipment 
that can be reprogrammed to accept the new EBT Card. The Seattle Smart 
Card might initially contain both a chip and a magnetic stripe contact 
interface to link with the EBT Project. Eventually, the State might adopt 
the Seattle Smart Card system as the next generation EBT card with 
potential savings in time and research and development costs. 

6.111-15.5 Transit Oriented Development - Fare Incentives and Secured 
Access 

RFCS cards would be used to provide fare incentives and secured access for 
participants in the six (6) Transit Oriented Development pilot projects, and for future 
expansion of the TOD concept. 
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6.111- 16 WSF Implementation Requirements 

6.111- 16.1 Description 

Washington State Ferries (WSF) intends to replace its existing revenue and traffic 
data systems starting in 2004 or 2005. Implementation in the WSF environment will 
include installation of electronic fare collection equipment in conjunction with this 
revenue and traffic data systems replacement. This Section outlines WSF specific 
requirements for RFCS equipment to be implemented in coordination with the 
revenue and traffic data systems replacement. 

6.111- 16.2 Commercial Account Program 

The Commercial Account Program is operated by Washington State Ferries to 
provide a post service payment mechanism to commercial account customers for the 
transportation of vehicles and staff on WSF ferry services. Commercial account 
customers include private organizations, as well as government, academic and other 
public institutions. Each Commercial Account has a unique identification number, 
which is used to check that the trip is charged to a valid account. 

Commercial Account customers are billed for actual trips taken at the normal full-fare 
cost. Frequency of use discounts are provided for certain fare types as described in the 
WSF Tariff. 

In addition to the Common Institutional Program Requirements described in Section 
6.II-2.2.1, the Contractor shall meet the following Commercial Account Program 
requirements: 

(a) The Commercial Account fare card shall be initialized with a six digit 
Commercial Account identification number, specific to each commercial 
account customer. All cards issued to the Commercial Account Customer shall 
have the same identification number. This shall be in addition to the card- 
specific unique serial number. 

(b) The Commercial Account payment option shall only be valid for travel on 
WSF services, and shall be valid for all forms of walk-on or vehicle-based 
travel. Transaction information shall be collected at WSF terminals. 

(c) At the point of use, the RFCS shall confirm that the Commercial Account 
Card and identification number are valid. Invalid cards shall be rejected, and 
the Commercial Account application on the card shall be blocked from further 
use. 

(d) Fares shall be computed at the time of card use, and adjusted with post-use 
frequency of use discounts, computed and applied per the provisions of the 
WSF Tariff. 
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(e) Payment shall be on a post-use billing basis. 

6.111- 16.3 On-Call Maintenance Service Levels 

In addition to the requirements described in Section 6.II-10.2.5.2, On-Call 
Maintenance Service Levels, the Contractor shall meet the following requirement: 

(a) For remote ferry locations (i.e., Anacortes, San Juans, Port Townsend and 
Keystone), Contractor shall arrive on-site within 4 hours rather then 90 
minutes. 

6.111- 16.4 WSF Implementation Criteria 

In conjunction with replacement of revenue and traffic data systems, WSF has 
identified a two step implementation of the RFCS. As the revenue and traffic data 
systems replacement project proceeds, a decision will be made on whether to 
implement these two steps sequentially or in parallel. 

Step 1: Walk-on Passengers. This includes the implementation of RFCS 
equipment to serve passenger-only routes, and walk-on customers on auto ferry 
routes in the system. 

Step 2: Vehicle Stream. This includes the implementation of RFCS equipment at 
all vehicle toll booths. 

6.111- 16.5 Data Collection System 

In addition to the Data Collection System requirements described in Section 6.III-12, 
Data Collection System, the Contractor shall meet the following requirement: 

(a) The Contractor shall provide appropriate environmental enclosures for the 

DACs that will be located at WSF terminals. Space restrictions will need to be 
accommodated at each terminal. 

6.111- 16.6 Data Exchange and Back Office Integration 

Washington State Ferries is in the process of replacing their existing Point of Sale 
system with a new Revenue Collection System (RCS). The Contractor shall meet the 
following requirements for the integration of RFCS equipment with the RCS: 

(a) All records shall be of transaction-level detail and will be used by the RCS to 
process transactions and generate reports. Transaction-level data will also be 
transferred to other WSF and Washington State Department of Transportation 
systems. An example of transaction level data recorded by the current POS 
system is included in Appendix B-6. 
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(b) The RFCS shall provide three interfaces to the RCS as illustrated in Figure 
III-16.1. The final architecture of the RCS and associated interfaces will be 
determined at Preliminary Design Review (CDRL 2). Interfaces shall include: 

i. A direct interface between FTPs installed at WSF toll booths and 
seller point of sale terminal. The point of sale terminal will 
determine the fare to be deducted (fare basis). The FTP shall act as 
a peripheral to, and be under the operational control of, the point of 
sale terminal. The FTP shall deduct fares based on a fare basis 
message from the point of sale terminal, shall generate transaction 
detail and acknowledgment messages for the point of sale terminal, 
and shall forward transaction data to the RFCS. 

ii. An interface between data acquisition computers installed at WSF 
and the RCS to transmit in near real-time fare transactions from 
Stand Alone FTPs, and transactions downloaded from Portable 
FTPs. 

iii. An interface between the Back Office Computer and RCS for back 
office data integration as described in Section 6.III-13. 


Figure MI-16.1 

WSF INTERFACES (To be finalized at PDR) 
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(c) The Contractor shall provide an Interface Control Document (DR 110.16) 
fully describing these interfaces. This information will be provided to the 
RCS system developer. 
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(d) For direct communications between the FTP and clearinghouse, a transparent 
path will be provided for batch data transfer through the RCS. The Contractor 
shall define requirements for such data transfer in DR 110.16. 


6.111-16.7 Food and Sundry Payment System (Option) 

In addition to the Non-Fare Applications described in Section 6.III-14, the Contractor 

shall provide a Food and Sundry Payment System meeting the following 

requirements: 

(a) The Contractor shall provide a food and sundry payment system on 
Washington State Ferries vessels (CDRL 40). 

(b) The food and sundry payment system shall be used for purchases from the on¬ 
board concessionaire. 

(c) The Contractor shall supply all equipment and facilities required for the food 
and sundry payment system including as a minimum: 

i. Card reading equipment co-located with all existing cash registers. 

ii. Communications/data transfer system. 

iii. Data management systems. 

(d) The Contractor shall make all arrangements with the on-board concessionaire 
to support the food and sundry payment system including as a minimum: 

i. Installation, operation and maintenance of equipment. 

ii. Revenue management. 

iii. Revenue reporting. 

(e) The system shall provide functionality to block/unblock the food and sundry 
payment application at the discretion of the cardholder. 

(f) Transaction time for food and sundry purchases shall be a maximum of three 
(3) seconds. 

(g) Customers shall not be required to enter a personal identification number or 
other information for purchases. 
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